#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)
Change History (20)
comment:1 Changed 14 years ago by jmroot (Joshua Root)
comment:2 Changed 14 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 14 years ago by michaelld (Michael Dickens)
| Attachment: | port_deactivate_stellarium.txt added |
|---|
results of command 'port -d deactivate stellarium' when stellarium is active
Changed 14 years ago by michaelld (Michael Dickens)
| Attachment: | port_activate_stellarium.txt added |
|---|
results of command 'port -d activate stellarium' when stellarium is not active
Changed 14 years ago by michaelld (Michael Dickens)
| Attachment: | ls_lAR_Stellarium.app_activated.txt added |
|---|
result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is active
Changed 14 years ago by michaelld (Michael Dickens)
| Attachment: | ls_lAR_Stellarium.app_deactivated.txt added |
|---|
result of command 'cd /Applications/MacPorts && ls -lAR Stellarium.app' when stellarium is not active
comment:3 Changed 14 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 14 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 14 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 14 years ago by michaelld (Michael Dickens)
Sorry, that might help: sudo ln -s /opt/local/Applications/MacPorts /Applications/MacPorts
comment:7 Changed 14 years ago by jmroot (Joshua Root)
And which one do you actually have configured as applications_dir?
comment:8 Changed 14 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 14 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 14 years ago by jmroot (Joshua Root)
| Attachment: | normalize-filepath.diff added |
|---|
comment:11 Changed 14 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 14 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:14 Changed 14 years ago by jmroot (Joshua Root)
| Milestone: | → MacPorts 1.9.1 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
OK, committed in r68864.
Just tried this with Lingon and it seems fine. My guess would be that the directories aren't actually empty (.DS_Store or whatever).