Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#25268 closed defect (fixed)

Deactivate does not fully remove (some) empty directories

Reported by: michaelld (Michael Dickens) Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.9.1
Component: base Version: 1.9.0
Keywords: deactivate, directory, removal Cc:
Port:

Description

In getting Stellarium.app to install correctly (checked in in [68848]), I did a lot of deactivating (via uninstall) and installing of that port while the Finder window for /Applications/MacPorts/ was open. After each uninstall I could see that Stellarium.app was still there, but no longer had an icon or Finder info associated with it. I can verify via an X11 terminal window that the basic directory structure was not actually removed -- just the files inside it were. The resulting top-level file (Stellarium.app) remained and cannot be used -- there is no executable in it, nor Info files describing it, just empty directories (or, directories of directories). Installing a new revision over these directories worked without issue, but after a deactivate the resulting top-level Stellarium.app obviously doesn't work.

I then tried deactivate with LaTeXiT and the same thing happens -- so I don't think this issue is specific to Stellarium; it seems to be a greater issue. While doing 'deactivate' with debug printing on, I can see that Port is, at least sometimes, checking whether or not the directory is empty, but it seems as though not all directories are checked. I can submit "port -d" if desired, but I'm sure whoever looks into this can do that too.

What I'm asking for is to fix checking whether a directory is empty during deactivate -- or, fix the list of what to deactivate & check for being empty, if that's the issue.

Attachments (5)

port_deactivate_stellarium.txt (158.9 KB) - added by michaelld (Michael Dickens) 10 years ago.
results of command 'port -d deactivate stellarium' when stellarium is active
port_activate_stellarium.txt (163.9 KB) - added by michaelld (Michael Dickens) 10 years ago.
results of command 'port -d activate stellarium' when stellarium is not active
ls_lAR_Stellarium.app_activated.txt (55.9 KB) - added by michaelld (Michael Dickens) 10 years ago.
result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is active
ls_lAR_Stellarium.app_deactivated.txt (19.3 KB) - added by michaelld (Michael Dickens) 10 years ago.
result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is not active
normalize-filepath.diff (1.2 KB) - added by jmroot (Joshua Root) 10 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 10 years ago by jmroot (Joshua Root)

Just tried this with Lingon and it seems fine. My guess would be that the directories aren't actually empty (.DS_Store or whatever).

comment:2 Changed 10 years ago by michaelld (Michael Dickens)

Doesn't seem to be extra files; maybe it's the ordering in which items are removed? Appending listings for Stellariom.app just to show it.

Changed 10 years ago by michaelld (Michael Dickens)

results of command 'port -d deactivate stellarium' when stellarium is active

Changed 10 years ago by michaelld (Michael Dickens)

results of command 'port -d activate stellarium' when stellarium is not active

Changed 10 years ago by michaelld (Michael Dickens)

result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is active

Changed 10 years ago by michaelld (Michael Dickens)

result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is not active

comment:3 Changed 10 years ago by michaelld (Michael Dickens)

Forgot to mention, if it make any difference: 10.5.8 Intel latest (except Safari 5.0) on a MacBook Pro 17" early 2009, XCode 3.1.3, MacPorts 1.9.0 .

comment:4 Changed 10 years ago by michaelld (Michael Dickens)

I am happy look into this issue myself, but I truly have no idea where to start since I deal with Portfile-s, not with 'port' functionality itself. Since it's not clear where this issue lies, I'd be tempted to look at the 'port' source first instead of messing further with the Portfile-s. If you / anyone wants to point me towards the source, I'll see what I can figure out.

comment:5 Changed 10 years ago by jmroot (Joshua Root)

What exactly is the relationship between /opt/local/Applications/MacPorts/Stellarium.app and /Applications/MacPorts/Stellarium.app here?

comment:6 Changed 10 years ago by michaelld (Michael Dickens)

Sorry, that might help: sudo ln -s /opt/local/Applications/MacPorts /Applications/MacPorts

comment:7 Changed 10 years ago by jmroot (Joshua Root)

And which one do you actually have configured as applications_dir?

comment:8 Changed 10 years ago by michaelld (Michael Dickens)

I'm not changing the applications_dir, so it is the default, which I presume is '/opt/local/Applications/MacPorts'. The symlink is just for my convenience, and otherwise shouldn't change how files are read or written.

comment:9 Changed 10 years ago by jmroot (Joshua Root)

Of course it shouldn't, but clearly it is. The default applications_dir is /Applications/MacPorts. Please check what your macports.conf actually says.

Changed 10 years ago by jmroot (Joshua Root)

Attachment: normalize-filepath.diff added

comment:10 Changed 10 years ago by jmroot (Joshua Root)

Please try this patch as well.

comment:11 Changed 10 years ago by michaelld (Michael Dickens)

I haven't touched the macports.conf file, but I had the default incorrect. Here's what the file says:

# Directory containing Applications from ports.
applications_dir        /Applications/MacPorts

So, possibly, my symlink was interfering with the expected behavior. I'll try your patch later tonight.

comment:12 Changed 10 years ago by jmroot (Joshua Root)

OK, so I would consider that a slightly odd setup, but we should still handle it correctly of course. Basically the problem is that that file normalize doesn't resolve symlinks in the version of Tcl shipped with 10.5 and earlier. We currently work around that for the parent directories of each file registered to the port, since otherwise we could end up deleting intermediate symlinks. It's OK to leave the path as-is when deleting the file itself, except it can mess up the sorting of the file list as seen here.

comment:13 Changed 10 years ago by michaelld (Michael Dickens)

Yes, that patch works for me.

comment:14 Changed 10 years ago by jmroot (Joshua Root)

Milestone: MacPorts 1.9.1
Resolution: fixed
Status: newclosed

OK, committed in r68864.

comment:15 Changed 10 years ago by michaelld (Michael Dickens)

Thanks!

Note: See TracTickets for help on using tickets.