Re: Hacking ZIP created on Windows for Mac OS X permissions

Subject: Re: Hacking ZIP created on Windows for Mac OS X permissions
From: Vojtěch Meluzín <email@hidden>
Date: Wed, 18 Sep 2013 14:53:00 +0200

Thanks Kevin. The reason is that indeed. But it's pretty obvious, that complicating a building step by yet another transaction into a Mac and back isn't exactly ideal. I read docs for ZIP and it seems there are "external attributes", which may contain permissions, but I tried to hack it, but it seemed like the Mac created attributes are just completely random, or I just don't get the numbers.

One more thing - I recently tried the "BetterZip" on my Mac and it turns out, it works well here. So it seems the permissions without "x" are created on some machines only.

About the DMGs - quite frankly, I consider this system pretty horrible, mounting images and stuff... It's so inconvenient. But it would be ok, if the DMG would actually run the installer upon mounting - is that possible? And is it possible to create such thing on Windows? Or at least let's say I have an APP file, the setup to be specific, and I want to create a DMG from just this app, which would run the APP after mounting. Is it possible to do this in command line? The reason is, that it is absolutely out of question to do this manually, so I need an automated approach.

Cheers!
Vojtech
www.meldaproduction.com

2013/9/16 Kevin Dixon <email@hidden>

As far as I know, ZIP does not support permissions on the files it
contains. If you really need to have specific permissions set, you
will get much more mileage by using the Package Maker that comes with
Xcode. I assume the reason you are doing the Zipping on a windows
machine is because its your build machine, but unless you use
PackageMaker, or create a DMG for your distributable, you will never
get the permissions to work the way you want.

-Kevin

On Sun, Sep 15, 2013 at 6:42 AM, Vojtěch Meluzín
<email@hidden> wrote:
> Hi folks,
>
> I know it's not really about AU, but it's about distributing AU, so I
> thought I'd try here :).
> Straight to the point - I'm distributing Mac OS X installers as ZIPs created
> on Windows (this cannot be changed). Everything is fine except for the god
> damn permissions - it turns out that every unzipper on Mac understands the
> external attributes (permissions) differently. My guess is that most of the
> unzippers except for the system defaults just don't get that the ZIP has
> been created on a different OS, so they just load the permissions despite
> they don't make sense on the system.
>
> What I'd like to know is, if there is a simple way to "post-process" the
> ZIP, so that it fills all the execute permissions as "set", the way the
> default unzippers do.
>
> I spent some time digging and it seems that this is a malfunction of the
> nondefault unzippers indeed and there is just no way to store crossplatform
> permissions accurately. It seems possible to hack the ZIP, but I'm kind of
> hesitating as the results may be, ehm, a little unpredictable. Does some
> know about some reasonable way? (and I really don't mean creating zips on
> Mac...)
>
> Thanks!
> Vojtech
>

> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References:
	>Hacking ZIP created on Windows for Mac OS X permissions (From: Vojtěch Meluzín <email@hidden>)
	>Re: Hacking ZIP created on Windows for Mac OS X permissions (From: Kevin Dixon <email@hidden>)

Prev by Date: Re: Strange problem with MidiClientCreate
Next by Date: HAL IO thread priority and glitching
Previous by thread: Re: Hacking ZIP created on Windows for Mac OS X permissions
Next by thread: Strange problem with MidiClientCreate
Index(es):
- Date
- Thread