Problem with Finder's "Compress"

Yes, I am aware of the root user, although I do usually think of it as an admin user doing something as root. Pretty much anything can be done from a regular admin account using sudo, so doing something like using the root account to compress with the Finder seems a bit odd (to me anyway), although I am a long way from being a system administrator.

This is part of what I was observing, in that usually (in other accounts) a zip file is unarchived with the permissions of the user, although using the unzip utility instead of the Finder gives you other options. Since Tiger apparently uses the -X option in the root account, it seems a bit backwards - the Finder then uses an option that in order to not use you need to use unzip, while Leopard doesn't use the option so you need to use unzip to include it. I don't use the root account at all, but I was thinking of the case where you would use the Finder to unzip some utilities or an application where you wanted the owner to be root, but the default is to preserve the original owner.

Hey Biovizier
This is completely unrelated to this thread. But I had to ask you a question regarding your post on a previous thread.
"http://discussions.apple.com/thread.jspa?messageID=6997442"
About filevault passwords - Now the issue was a person's macbook was locked by her relative using filevault & master password was set. And I fixed it using your method. Now at the login window of the user, there is a "Reset Password" option and when I try to reset the Master Password, it says "The user's previous keychain still exists...."
Does this the mean the person whoever locked the computer can still lock the computer again using the previous password?
I know can make that Reset Password option dissapear by deleting the FileVault.pref files but could that person use the old password to lock the computer again? Or is there a way to delete those preference files?

..." wouldn't the bug be in Tiger for adding that option?"...

I think it's important to make a distinction between a bug (something works differently from how it was intended due to eg. an error during programming), and a design decision that people may disagree with.

Since ' ditto' is supposed to, but fails to restore the ownership information in Leopard, and "Archive Utility.app" works through ' ditto', and since the ownership information is present in the archive that is created by "Archive Utility.app", and since ownership was restored by all of these methods (or their equivalents) in "Tiger", I'm assuming that ownership is intended to be preserved in Leopard but isn't preserved because of a bug. If someone knows of any new syntax for "Leopard" to do this, I would love to hear it, but right now, the closest approximation seems to be ' unzip' + ' FixupResourceForks' which creates an imperfect copy with alterred folder modification dates, so it does not appear to be possible to properly extract a "Finder" archive in Leopard at all. That can't be intentional.

Now, whether archiving, or copying in the "Finder" should or shouldn't preserve ownership is a whole other debate. I'm of the opinion that "root" should preserve ownership. "frazzlejazz" gives a good real-world account of why such a feature is desireable.

One important thing to keep in mind is that non-root user's can't preserve ownership even if they wanted to - they don't have the privileges so making everything owned by them is the best that they can do. The "root" user does have the privileges to preserve ownership, and they won't have any access issues no matter who owns the item so there is not inherent reason to change the ownership. With the ability to preserve ownership, they potentially can (with a few exceptions) make a perfect copy of a source folder (very handy for an administrator overseeing multiple accounts) and it seems to me that it would be a shame to cripple that ability just to make it the same as less privileged users.

..." 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?"...

Again, I find it difficult to imagine why someone logged in as "root" would need ownership of the files in an expanded archive. For less privileged users, it's a necessity, but not for "root" because they can already access anything. But I suppose if they really needed to, under Tiger, they could expand the archive (original ownership preserved), then copy the expaned folder (the new copy owned by "root"). For something with straightforward permissions like an application, the Tiger version of "Get Info" with the "Apply to enclosed items" should have sufficed, and you wouldn't even need to log into "root" to do it. For a more complex folder whose contents have different owners and permissions, and hypothetically, if the "Finder" also were to preserve ownership, then I suppose it would be necessary to go to the command line to change just the ownership to "root" without alterring permissions, but it would be possible to do so.

But look at the converse - once you have a folder where ownership of everything has been changed to "root", how do you get your perfect copy back? Once the specific ownership information is gone, it can't be restored, neither with the GUI nor the CLI. The best case scenario is you know what should belong to whom and go through each file and fix them individually.

So in terms of design decisions, I would go with the option to preserve as much information as possible in an archive, which for "root", means preserving ownership.

It appears that Leopard's Finder uses ditto's PKZIP option, which will unzip with permissions for the current owner. Using ditto's default CPIO will uncompress preserving the original ownerships and permissions, so it looks like this is one of those design decisions.

..." It appears that Leopard's Finder uses ditto's PKZIP option, which will unzip with permissions for the current owner."...

That shouldn't matter -- ' ditto' is supposed to preserve ownership when run as "root". That it fails to do so in Leopard for PKZip format archives is the bug.

..." Using ditto's default CPIO will uncompress preserving the original ownerships and permissions"...

True, but since the "Finder" uses the PKZip format, the fact that expansion of CPIO archives works correctly unfortunately won't help in the proper expansion of "Finder" archives in Leopard. Unless you're saying you figured out a way to get ' ditto' to do this...

The default archive for ditto is CPIO, which does preserve the ownerships.

Using the PKZIP option (which seems to be what the Finder uses) does not, but it is difficult to track down whether or not a regular .zip archive is supposed to preserve the ownership. The owner/group seems to have been added a while back, but the documentation on what the default actions are for PKZIP is hard to nail down. Zipinfo shows some additional flags in there, but doesn't describe what they are, so your guess is as good as mine (OK, it's probably a lot better).

Actually, I was referring specifically to the expansion of "Finder" archives (PKZip archives) in Leopard when I said ' ditto' doesn't preserve ownership. I tried to include either "archive" or "expand" whenever mentioning the problem but in case I got sloppy at some point, sorry for the confusion.

And with respect to other types of archives, I did mention that those created by drag-and-drop with "ArchiveUtility.app" (compressed CPIO) could be correctly expanded using ' ditto'. Straight folder-to-folder copies (like the output you just posted, if I'm reading it correctly) never really came up in the context of this thread, but they work correctly (I suspect if they didn't, that would have been noticed much more quickly by somebody by now).

So, yes, it is specifically this form of the command that fails to restore ownership on expanded archives in Leopard, when run as "root" in 10.5:<pre>
ditto -x -k /path/to/archive.zip /path/to/destination</pre>

The actual bug might not be in ' ditto' itself though, since a copy of the 10.4 version of ' ditto' fails in the same way when run on a 10.5 system...

Great! Keep us posted...

Thanks for the update.

Incidentally, "Finder" and ' ditto' also seem to share a peculiarity in the handling of a certain ACL rule (I forget which off hand) during copying, behaving differently compared to other tools like ' cp'.

The two issues may or may not be related, but the whole area could probably use a big overhaul bug fix - hopefully we'll get one while still in 10.5...