Unarchived folder has different permissions to those set by Archive Utility

[GoogleCodeExporter]

I had serious problems using Eclipse due to folder permissions. I discovered 
that the problem was 
that The Unarchiver gave different permissions to the unarchived folder 
compared to those set by 
Archive Utility.

The eclipse zipped file I unarchived had permissions -rw-r--r--
The unarchived eclipse folder from The Unarchiver has permissions drwxrwxr-x
The unarchived eclipse folder from Archive Utility  has permissions drwxr-xr-x

So group has write permission from The Unarchiver but not from Archive Utility.

I am not sure how you determine what the permissions should be so I am raising 
this as a defect 
for you to investigate. May not be a defect though depending on the design and 
whether or not you 
should be the same as Archive utility.

Original issue reported on code.google.com by tmow...@talktalk.net on 5 Feb 2010 at 10:20

[GoogleCodeExporter]

I will need the actual file before I can investigate anything.

Also, which version of The Unarchiver were you using?

Original comment by paracel...@gmail.com on 5 Feb 2010 at 1:00

• Changed state: NeedsFiles

[GoogleCodeExporter]

The Unarchiver v2.2

You can download the actual file from Eclipse thus:

(1) Go to URL:   http://download.eclipse.org/eclipse/downloads/
(2) Click the 3.6M5 link
(3) Click the "(http)" link for the Mac OSX (Mac/Cocoa/x86_64) build

I downloaded from the UK FTP mirror

Original comment by tmow...@talktalk.net on 5 Feb 2010 at 4:14

[GoogleCodeExporter]

I don't think there are any relevant changes, but try 2.3 anyway just to make 
sure.

Original comment by paracel...@gmail.com on 5 Feb 2010 at 4:23

[GoogleCodeExporter]

I have installed and tested 2.3 and the result is the same.

Original comment by tmow...@talktalk.net on 6 Feb 2010 at 11:26

[GoogleCodeExporter]

Archive Utility.app and TheUnarchiver.app handle permissions embedded in 
archives differently. Archive 
Utility.app behaves like tar (bsdtar, in this case) WITHOUT the p (preserve 
permissions) switch. 
TheUnarchiver.app behaves like tar WITH the p switch.

This seems more like a design decision than an actual bug -- though it might be 
worth having at least a 
configuration option on this behaviour at some point? Will need to be careful 
changing it, unless it's already 
an option in the archive library TheUnarchiver uses, as some permissions are 
preserved (such as +x) even 
without the p switch in tar.

Attached is a small archive that contains a folder with a small sampling of 
files/directories named after their 
permission state when archived. If you want a demonstration, try extracting 
with Archive Utility.app, 
TheUnarchiver.app, tar zxfv, and tar zpxfv, then compare the results on the 
extracted files.

Original comment by broken0chaos@gmail.com on 17 Feb 2010 at 10:37

Attachments:

• permissions-test.tar.gz

[GoogleCodeExporter]

Ah yes, that sounds like a good explanation of what's going on. And yes, that 
would take some careful 
consideration to figure out what the best behavior would be.

Original comment by paracel...@gmail.com on 17 Feb 2010 at 10:50

• Changed state: Accepted
• Added labels: Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Digging through the libarchive/bsdtar source code, specifically 
archive_write_disk.c 
(http://www.opensource.apple.com/source/libarchive/libarchive-
13.1/libarchive/libarchive/archive_write_disk.c), I found the code to do with 
how it handles restoring 
permissions without the p switch. I can't say if this is *exactly* how Archive 
Utility handles it or not, but it 
would seem to be a sane default.

Specifically, the comments in the code (around line 400) say "User didn't 
request full permissions, so don't 
restore SUID, SGID bits and obey umask.". The default umask in OSX is 
(converted to octal) 755 (or -rwxr-xr-
x). So I imagine this means any SUID bits, SGID bits (I'm not sure if 
TheUnarchiver even does anything with 
these as it is) are discarded, and the *maximum* permissions allowed are 755. 
Anything *less* than that (i.e. 
400, 555, 644, etc.) are followed. Anything *more* than that will get dropped 
down, such as 777 getting 
dropped to 755, or 664 getting dropped to 644.

There's some more possibly-interesting stuff in the bsdtar source code on how 
it handles (or more 
specifically, ignores) ACLs, XATTRs, and FFLAGS (though I have no idea what an 
FFLAG is, to be honest) when 
the p switch is not set. It's around line 311 of bsdtar.c 
(http://www.opensource.apple.com/source/libarchive/libarchive-13.1/libarchive/ta
r/bsdtar.c).

The entire source archive of the Apple version of libarchive/bsdtar is also 
available as a tar archive, if anyone 
wants to have a closer look at the entire thing 
(http://www.opensource.apple.com/source/libarchive/libarchive-13.1/libarchive-2.
6.2.tar.gz).

Original comment by broken0chaos@gmail.com on 20 Feb 2010 at 6:02

[GoogleCodeExporter]

Well, I decided to change to the Archive Utility behavior instead.

I'm working on some entirely new unarchiving code, which has an option for 
whether to preserve permissions or 
not, but the old XADArchive code doesn't.

I guess I'll call this fixed for now.

Original comment by paracel...@gmail.com on 2 May 2010 at 7:40

• Changed state: Fixed

[GoogleCodeExporter]

> Well, I decided to change to the Archive Utility behavior instead.

I think this is the wisest solution because The Unarchiver is offered as a 
replacement for Archive Utility so 
users are apt to do exactly that, and they will assume that The Unarchiver will 
work just like the Archive Utility 
(like I did). Whether that assumption is wise or not that is what is likely to 
happen.

Also well done on a great utility which I use as standard on my system.

Regards,

Tim

Original comment by tmow...@talktalk.net on 3 May 2010 at 6:08

[GoogleCodeExporter]

I have users with Theunarchiver having problems unzipping an installer .pkg 
because the install scripts in the Resources folder of the .pkg end up with 
masked permissions so cannot be run the by the OSX installer which runs as root.

To date, I've suggested they uninstall theunarchiver to fix the problem - but 
be great if you guys make the behaviour the same as the standard OSX unzip 
utility.

Original comment by adambill...@googlemail.com on 3 Jan 2012 at 6:30