Problem with Finder's "Compress"

frazzlejazz wrote:
I'm having a real problem in Leopard with the Compress option in Finder's File menu. After enabling the root user and logging in to it, I create a .zip file of a folder using the Compress option.

What does root user have to do with this?
Anyone can right-click and compress a file.

Why not just use a backup program like Carbon Copy Cloner or SuperDuper?

They'll both back up your whole hard drive very easily.

You can use
compress
in a terminal
sudo zip
should allow you to compress all the files

As far as I know, compressing a folder (also putting it in a disk image) will result in the uncompressed copy taking on the ownership of whoever unzipped it, the same as making a copy of a file takes on the ownership of the one copying it. It works the same way in Tiger, so I'm not sure what options you were using to zip the file (it would make downloading stuff from various websites a crapshoot otherwise). You will probably need to use one of the cloning utilities to make an archive that retains permissions.

Come on, you can do better than that. Your profile lists a Tiger machine so you are in good shape to see for yourself what the OP is talking about...

Sorry, no.

If I archive in TIger (or compress in Leopard) and then unzip/uncompress from another user, the unzipped files/folders have the ownership of that user, not the original. This makes some sense, in that unzipping the archive makes a copy, and making a copy of a file owned by another user also results in the copy having the ownership of the user making the copy.

I don't know what options the Finder uses for the archive/compress, but I didn't see anything in the man pages about an option that preserves the ownership in the unzipped copy. If there is one, it would most likely not normally be used by the Finder, since I have not come across any .zip file that unzipped to a different owner. I would also suspect that if this were not true, some mayhem would ensue as people shared zip files without fixing the ownership option.

Try it as "root" as per the OP...

I see your point - it appears that once again, something that worked well and simply in Tiger has been bungmangled in Leopard.

As far as I can tell, "nerowolfe" seems to have been on the right track since running ' unzip', as "root", with the ' -X' flag expands a Leopard Finder ctrl-click archive while preserving ownership. The ' -K' flag (apparently to preserve the sticky bit, etc.) might also be needed depending on what is being zipped.

However, if any of the files had extended attributes or resource forks, these are expanded into a separate folder from the main folder. They can be restored by merging the two folders and running ' FixupResourceForks', but this alters some of the modification dates so isn't ideal.

I suspect there is an easier one-step method that preserves both metadata and ownership buried in the ' man' pages somewhere, but I haven't been able to spot it yet...

If your main goal is to use built-in tools for archiving purposes, note that "/System" > "Library/" > "CoreServices" > "ArchiveUtility.app" creates nice compact ".cpgz" files that can be expanded using the same utility, or using ' ditto', keeping ownership and metadata intact (at least if using 10.5 versions). However, it doesn't seem to wrap up multiple selections into a single archive like the ctrl-click contextual menu does.

Just to follow up on this, I'm beginning to suspect you have uncovered an actual bug.

In the 10.5 "Finder", the creation and expansion of archives is handled by "Archive Utility.app", which in turn appears to act through ' /usr/bin/ditto'. In "Tiger", compressing / expanding using ' ditto' is a fully reversible process (preserving owners, file attributes, resource forks, dates, etc.), whereas in "Leopard", just like the "Finder", ' ditto' fails to preserve ownership on expanded archives. It's possible that something with respect to the syntax for ' ditto' has changed (as has been the case with a few other commands) due to 10.5 having been certified as officially unix compliant, but the problem appears to be at least as deep as the level of the command line tool ' ditto.

Interestingly, 10.4's "BOMArchiveHelper.app" (which seems to work in 10.5 in other respects) and does not seem to act through ' /usr/bin/ditto', also fails to preserve ownership when used in Leopard, so this could mean that the bug is deeper, maybe at the point of some system call common to both ' ditto' and "BOMArchiveHelper.app".

Regardless, it is probably worth submitting a bug report to Apple, which you can do by following this link:
http://developer.apple.com/bugreporter

I think that with a straight "Finder" copy, it is normal for everything to end up being owned by the user making the copy, as alluded to by "red_menace". It might not be ideal, but I think that's way it has always worked.

re: bug reporting, you don't have to be a developer to submit a bug report. Registration is required, but anyone can do so, and it is free.

Originally, I was thinking that the change in terminology from "Archive" to "Compress" indicated an intentional change in the behaviour, in which case filing a bug reported would be met with an unceremonious "intended behaviour" response. However, the fact that a standard tool like ' ditto' is exhibiting the same behaviour is why I now think it is a bug, which might at least have a chance of being fixed.

I'll probably wind up looking like an idiot again (won't be the first/last time, either), but wouldn't the bug be in Tiger for adding that option? If for whatever reason you log in as root, then for whatever reason use the Finder to uncompress something that you wanted to be owned by root, how would you stop this behavior? And if you are going to have to use one of the various utilities to uncompress in the desired way, why use the Finder in the first place? Or log in as root for that matter? It seems like Leopard is the way to do it (minimal options), although it also seems like they are still trying to figure out how to use the Finder in the root account.