Welcome to the MacNN Forums.

Severed Hand of Skywalker · Aug 1, 2003, 05:14 PM

I am understand that compressing something as a zip which is a PC format that you will lose the Mac resources in it.

For example if you compress a mac font or App as a ZIP it will be corrupt when you unzip it.

Correct?

JLL · Aug 1, 2003, 05:22 PM

Originally posted by Severed Hand of Skywalker:
I am understand that compressing something as a zip which is a PC format that you will lose the Mac resources in it.

For example if you compress a mac font or App as a ZIP it will be corrupt when you unzip it.

Correct?

Mac OS X doesn't need resources.

clarkgoble · Aug 1, 2003, 05:27 PM

Apple's been strongly downplaying resources over bundles since OSX came out. So no new apps really ought to be using them in datafiles.

Zip files are used because it isn't patented anymore and because it is crossplatform. XP's built in compression which Apple is mimicking it follows it.

Adam Betts · Aug 1, 2003, 06:28 PM

IMHO, ZIP is more flexible and better than crappy SIT.

AladdinSW have went all the way down so I don't blame Apple for turning them down.

Wevah · Aug 1, 2003, 07:15 PM

Why not gzip?

geekwagon · Aug 1, 2003, 07:55 PM

Originally posted by Wevah:
Why not gzip?

Gzip can only compress one file at a time. It's pretty no-frills as far as compression standards go. Works OK for compressing files that are already globbed together though, like a tarball or a disk image, or for compressing a stream like the output of another program..

I think it is obvious that Apple is downplaying resources because they are trying to make it easier for Macs to interoperate with everyone else. When you are dependent on some filesystem feature that no other OS on the planet implements, it can make life hard on your users. I for one am in no hurry to go back to the world of binhexing files so they stay intact..

CharlesS · Aug 1, 2003, 08:19 PM

Originally posted by geekwagon:
Gzip can only compress one file at a time. It's pretty no-frills as far as compression standards go. Works OK for compressing files that are already globbed together though, like a tarball or a disk image, or for compressing a stream like the output of another program..

I think it is obvious that Apple is downplaying resources because they are trying to make it easier for Macs to interoperate with everyone else. When you are dependent on some filesystem feature that no other OS on the planet implements, it can make life hard on your users. I for one am in no hurry to go back to the world of binhexing files so they stay intact..

The thing is that .tar.gz is the standard in the UNIX world, and a much better format than .zip, which IIRC doesn't even preserve permissions correctly. Why they would choose .zip over .tgz is a mystery to me as well.

Zimphire · Aug 1, 2003, 08:22 PM

Originally posted by CharlesS:
The thing is that .tar.gz is the standard in the UNIX world, and a much better format than .zip, which IIRC doesn't even preserve permissions correctly. Why they would choose .zip over .tgz is a mystery to me as well.

Compatibility with 90% of the computer world maybe?

trusted_content · Aug 1, 2003, 09:11 PM

Originally posted by geekwagon:
Gzip can only compress one file at a time. It's pretty no-frills as far as compression standards go. Works OK for compressing files that are already globbed together though, like a tarball or a disk image, or for compressing a stream like the output of another program..

man gzip

Code:
ADVANCED USAGE
       Multiple  compressed  files  can  be concatenated. In this
       case, gunzip will extract all members at once.  For  exam-
       ple:
:
             gzip -c file1  > foo.gz
             gzip -c file2 >> foo.gz

       Then
             gunzip -c foo

       is equivalent to

             cat file1 file2

In any case, I think you should at least be able to set what sort of compression you want. With the files I move around, it makes much more sense to make a .tgz then a .zip... I'd like to be able to specify that that's how I like it done.

geekwagon · Aug 1, 2003, 09:12 PM

Originally posted by CharlesS:
The thing is that .tar.gz is the standard in the UNIX world, and a much better format than .zip, which IIRC doesn't even preserve permissions correctly. Why they would choose .zip over .tgz is a mystery to me as well.

Your right of course, .tgz is the standard and it does perserve permissions where .zip does not. Those features are provided by tar though not .gz.

I can see why they would use .zip though since so many people use it and it is so standard. And since right now most software distribution is done via disk images maybe they felt that it wasn't worth it to put a graphical front end on tar or cpio. Who knows that .zip will be the only thing they use though? Panther is still far from shipping. It doesn't even have a release date announced yet.

Wevah · Aug 1, 2003, 09:33 PM

I'd be fine with it if I could chose between ZIP or tar/gzip (or maybe even tar/bzip2?) each time.

moreno · Aug 1, 2003, 10:05 PM

am understand that compressing something as a zip which is a PC format that you will lose the Mac resources in it.

For example if you compress a mac font or App as a ZIP it will be corrupt when you unzip it.

Correct?

.DS_Store?

Developer · Aug 1, 2003, 10:39 PM

Originally posted by moreno:
.DS_Store?

Has to do with the resource fork what?

step · Aug 1, 2003, 10:48 PM

so it'll strip out all the custom icons and thumbnails for all my jpgs and psd files? that's not handy

Severed Hand of Skywalker · Aug 1, 2003, 11:46 PM

Originally posted by step:
so it'll strip out all the custom icons and thumbnails for all my jpgs and psd files? that's not handy

Exactly, plus if I stuff an App or a font what will happen to them?

Superchicken · 11:56 PM

Makes sense. You can still stuff things if you want to, stuff-it is still around as are other compression utilities.

Does this help?

Severed Hand of Skywalker · Aug 1, 2003, 11:54 PM

Originally posted by Superchic[k]en:
Makes sense, you can still stuff things if you want to stuff it is still around as are other compression utilities.

Do i need a decoder ring to make that one out or something?

CharlesS · Aug 2, 2003, 12:10 AM

Originally posted by Zimphire:
Compatibility with 90% of the computer world maybe?

Most Windows users I know are able to deal with .tgz files I send them with no trouble at all.

Superchicken · Aug 2, 2003, 12:14 AM

zip scares my mom... I don't know what she'd do with tgz

Ilja · 04:37 AM

AFAIK Winzip can unzip almost every compressed format, so the argument that 90% of the computer-users use zip is not a real good argument IMO

dazzla · Aug 2, 2003, 03:53 AM

The zip format isn't static and set in stone though is it? I was under the impression that if needs be, it can be extended to support resource forks.

Besides, it's more then likely using it's built in archiving facilities and this is a front end for it, it wouldn't surprise me that either Apple enable an option to choose between what OS X can compress (less likely) or someone releases a little haxie or something, or a terminal command to change what format it compresses in.

Mr Scruff · Aug 2, 2003, 05:05 AM

Why would a non unix-using OS X user need to preserve permissions? Not saying that they wouldn't, I just can't think of a situation where it would be necessary (or even desirable).

Cipher13 · Aug 2, 2003, 05:16 AM

Apple cannot just go and downplay the importance of resource forks; hell, some things still use them.

What happens when somebody goes to compress an old file? Bam. No good.

There must be a resource-friendly alternative. Err. Yeah.

Originally posted by Zimphire:
Compatibility with 90% of the computer world maybe?

If that was such a massive concern for us, we'd all be running Windows...

Cipher13 · Aug 2, 2003, 05:18 AM

Originally posted by Mr Scruff:
Why would a non unix-using OS X user need to preserve permissions? Not saying that they wouldn't, I just can't think of a situation where it would be necessary (or even desirable).

Whether the user knows it or not, permissions are still of utmost importance to the functioning of their system... just because they don't actively play with permissions doesn't mean they aren't important.

brainchild2b · 05:40 AM

We are all running windows, at work, at everyone else's house. If you (the only mac users on earth who doesn't have to use a pc as well) want to use .sit you can continue to do so.

Having .zip is a great step forward. It means it will work on my mac, my pc, and linux if we really need to.

rather than some .tar.gz crap that a average user will just go "WTF?"

.zip is the standard that the world uses for compression. Sometimes you just have to fit it. It's fine if you want to stand out and be different but the majority of us have to work in a REAL world, with REAL clients, and REAL people who don't know crap about comptures.

Cipher13 · Aug 2, 2003, 05:31 AM

Originally posted by brainchild2b:
You idiot

How petty of you. I thought you were better than that... and then I remember who I'm conversing with.

Originally posted by brainchild2b:
we are all running windows, at work, at everyone else's house. If you (the only mac users on earth who doesn't have to use a pc as well) want to use .sit you can continue to do so.

Having .zip is a great step forward. It means it will work on my mac, my pc, and linux if we really need to.

rather than some .tar.gz crap that a average user will just go "WTF?"

.zip is the standard that the world uses for compression. Sometimes you just have to fit it. It's fine if you want to stand out and be different but the majority of us have to work in a REAL world, with REAL clients, and REAL people who don't know crap about comptures.

So, why not just switch to Windows then? I mean, if everyone ELSE uses it...?

Heh. Have you even read this thread? Resource fork issues?

Sigh. Why do I even bother with you.

brainchild2b · Aug 2, 2003, 05:42 AM

Sorry I'm on a warpath today and cranky from deal with stupid users on various networks.

Stuffit is still included with Mac OS X Panther (latest beta). Users concerned about this can continue to use stuffit. Apple may provide a way to add in the resources forks. The zip compression is very beta. Hopefully people will continue to re-write there apps.

Interoperbility and the easiest compatibility is required with Windows. It's just a must for our enviroment.

I hate using windows but it's everywhere. It's part of my job, and it's the computer that's in everyone else's houses. When i send a file to a client of course i'd .zip it without even thinking.

Anybody who has mac os x, you would mostly know on a first name basis, almost like it's that "special club". And i'd know which compression to use.

But for the average joe, or a switch .zip is better.

JLL · Aug 2, 2003, 06:11 AM

Originally posted by Cipher13:
Apple cannot just go and downplay the importance of resource forks; hell, some things still use them.

Apple IS downplaying them and has been for years - and if an app solely relies on resource forks, the programmers need to get up to date.

Do you have an example?

JLL · Aug 2, 2003, 06:12 AM

Originally posted by Cipher13:
Whether the user knows it or not, permissions are still of utmost importance to the functioning of their system... just because they don't actively play with permissions doesn't mean they aren't important.

One word: umask

Developer · Aug 2, 2003, 06:25 AM

Originally posted by JLL:
Apple IS downplaying them and has been for years - and if an app solely relies on resource forks, the programmers need to get up to date.

Do you have an example?

Finder: user open resource: Change the application a document is opened with in the Get Info dialog and that information is stored in the resource fork.

JLL · Aug 2, 2003, 07:40 AM

Originally posted by Developer:
Finder: user open resource: Change the application a document is opened with in the Get Info dialog and that information is stored in the resource fork.

No it's not - that's handled by Launch Services.

Developer · Aug 2, 2003, 08:05 AM

Originally posted by JLL:
No it's not - that's handled by Launch Services.

Well, I have no particular knowledge whether it's the Finder itself or Launch Services that adds the user open resource, but that's nit picking, isn't it?

macmike42 · Aug 2, 2003, 08:16 AM

Originally posted by Developer:
Well, I have no particular knowledge whether it's the Finder itself or Launch Services that adds the user open resource, but that's nit picking, isn't it?

No, LaunchServices doesn't use resources either...

The fact remains, however, that if you zip a PostScript or Mac OS 9-style font (both of which integrate perfectly with OS X), and then unzip it, you have a useless file. Maybe Apple used the same hack they used with Installer.app and UFS (hidden files contain resource data in the data fork).

Developer · Aug 2, 2003, 08:25 AM

Originally posted by macmike42:
No, LaunchServices doesn't use resources either...

JLL · Aug 2, 2003, 08:25 AM

Originally posted by Developer:
Well, I have no particular knowledge whether it's the Finder itself or Launch Services that adds the user open resource, but that's nit picking, isn't it?

No because saving the info in a plist has absolutely nothing to do with resource forks.

Developer · Aug 2, 2003, 08:29 AM

Originally posted by JLL:
No because saving the info in a plist has absolutely nothing to do with resource forks.

Can you tell me where you can see the word 'plist' in my post?
Of course you could have just tried to change the app for a file and actually have a look into that files resource fork, but I guess it's so much more convenient just talking out of you smart

.

Adam Betts · Aug 2, 2003, 09:56 AM

Originally posted by Cipher13:
Sigh. Why do I even bother with you.

Honestly, I think he shouldn't bother with you since you have a rock-solid head and won't even admit that you're wrong sometime

Spheric Harlot · Aug 2, 2003, 10:08 AM

Wow.

Are you all drunk or something?

How about some normal conversation?

Developer, from what I've understood, your example of using Get Info to change the program a document is opened with does NOT use resource forks. That information is stored in a .plist file by LaunchServices, not in the file itself.

Resource forks do not enter into the equation.

-s*

Angus_D · Aug 2, 2003, 10:13 AM

Originally posted by Severed Hand of Skywalker:
Exactly, plus if I stuff an App or a font what will happen to them?

Depends on the app or font. Only CFM apps can have resource forks. Bundled Mach-O apps won't have resource forks (unless there's something really screwy going on, it could have resource forks in its support files but that would be a stupid way of working).

Similarly, I think fonts are now stored in the datafork by default and Apple has tools for swizzling them around somewhere.

Originally posted by JLL:
No because saving the info in a plist has absolutely nothing to do with resource forks.

Not entirely true. For unbundled CFM applications, LaunchServices looks for a "plst" resource, which is just the plist but stored inside the resource fork of the application.

As far as the whole what application handles what gubbins, that's all stored in the LaunchServices database, which is maintained in data files scattered all over the place. If your LS database becomes corrupted, you can get screwy behaviour like drag and drop breaking (I've had this happen a few times).

stew · Aug 2, 2003, 10:19 AM

BeOS has a zip command that preserves all the additional file attributes and the multiple forks. Why shouldn't Apple do the same?

dazzla · Aug 2, 2003, 10:22 AM

Has anyone actually tried the zip function with an app with resource forks? We could all be bickering over nothing

Developer · Aug 2, 2003, 10:35 AM

Originally posted by Spheric Harlot:
Developer, from what I've understood, your example of using Get Info to change the program a document is opened with does NOT use resource forks. That information is stored in a .plist file by LaunchServices, not in the file itself.

Resource forks do not enter into the equation.

What you have understood is wrong. The resource fork does enter into the equation, as you could have easily verified by actually looking at it after changing the application binding for a file.

nickm · Aug 2, 2003, 12:29 PM

When you are dependent on some filesystem feature that no other OS on the planet implements, it can make life hard on your users.

NTFS implements multiple stream files, and it wouldn't be too difficult to have a standard interchange between the two if the computer world wanted to.

The problem, of course, was that even if you could get the resource fork onto an NTFS file system, some windows programs would mess it up.

I don't mind Apple using zip provided they give you a warning that data will be lost (kind of like when you save your rich text files as plain text).

Skywalkers new Hand · Aug 2, 2003, 01:43 PM

Originally posted by nickm:
I don't mind Apple using zip provided they give you a warning that data will be lost (kind of like when you save your rich text files as plain text).

Why do people compress things anyway? It is NOT to save space on hard drives anymore.

People use it so when they upload a file or email it the contents hold on to their resources.

For example, when I put a quark file on an FTP it has to be compressed or the fonts are lost.

So if the point is to hold on to the resources during transmission yet zip strips it all anyway what the heck is the point?

Art Vandelay · Aug 2, 2003, 01:44 PM

Originally posted by Developer:
What you have understood is wrong. The resource fork does enter into the equation, as you could have easily verified by actually looking at it after changing the application binding for a file.

True, but I think what they meant is that if you have a file without a resource fork, then it doesn't add a resource fork if you change its default app. Your argument is true for files that already have resource forks. Their argument is true for files that don't.

Art Vandelay · Aug 2, 2003, 01:46 PM

Originally posted by nickm:
NTFS implements multiple stream files, and it wouldn't be too difficult to have a standard interchange between the two if the computer world wanted to.

The problem, of course, was that even if you could get the resource fork onto an NTFS file system, some windows programs would mess it up.

I don't mind Apple using zip provided they give you a warning that data will be lost (kind of like when you save your rich text files as plain text).

The majority of Windows user are still using FAT32. XP was the first consumer Windows OS to support NTFS.

Developer · Aug 2, 2003, 01:55 PM

Originally posted by Art Vandelay:
True, but I think what they meant is that if you have a file without a resource fork, then it doesn't add a resource fork if you change its default app. Your argument is true for files that already have resource forks. Their argument is true for files that don't.

Their argument is wrong. If a file doesn't have a resource fork, one is added the moment you change the application binding for that file.

Art Vandelay · Aug 2, 2003, 02:06 PM

Originally posted by Developer:
Their argument is wrong. If a file doesn't have a resource fork, one is added the moment you change the application binding for that file.

I just tested that and you're right. That goes against everything I've read so far. It does create a resource fork to store the default app. Yep, they are wrong.

JLL · Aug 2, 2003, 02:30 PM

Originally posted by Developer:
Their argument is wrong. If a file doesn't have a resource fork, one is added the moment you change the application binding for that file.

Yes for that file alone - you didn't exactly specify that.

But since the option as far as I can see is meant for zipping files that you email to others, it's basically a non issue.

And as other have said: who knows if zip will be the only option.

Tsilou B. · Aug 2, 2003, 02:35 PM

Originally posted by stew:
BeOS has a zip command that preserves all the additional file attributes and the multiple forks. Why shouldn't Apple do the same?

Yep, that's right. In BeOS PR1 the default compression format was changed from tgz to zip and they explicitly said that the reason was: "zip supports multiple forks and tar (and tar.gz/tgz) does not".