Welcome to the MacNN Forums.

Alexia · Apr 3, 2007, 04:11 PM

Is there a way to prevent OS X from making archives littered with junk in them that are normally hidden to OS X? The reason is, the zip file I am making is used by a lot of Windows users, so the extra MACOSX folder with the same folder name inside of it as the main folder outside confuses them.(Try to imagine the night mare of trying to get some one to install the correct folder.)

Yes, the information is useful to an OS X user, but works fine without it.

peeb · Apr 3, 2007, 04:55 PM

Finder Cleaner will remove them, and there is a preference to stop OSX from creating 'Mac Spore' on network drives. It's very annoying, and I wish Apple would fix this anti-social behavior.

Chuckit · Apr 3, 2007, 05:32 PM

Originally Posted by peeb

Finder Cleaner will remove them, and there is a preference to stop OSX from creating 'Mac Spore' on network drives. It's very annoying, and I wish Apple would fix this anti-social behavior.

What on earth is "anti-social" about including Mac-specific data in a MACOSX folder in zips created by the Finder? Would you prefer it if zipping files had the potential to destroy them?

peeb · Apr 3, 2007, 06:41 PM

It's anti-social because if a Mac accesses a shared drive on a network it leaves a lot of meta-data files all over the place that are visible to Windows machines. There should be a way to track that without proliferations of files in every directory that the Mac accesses. It's most annoying to Windows users. When I use my Apple to manage music on my iRiver, for example, as well as the .mp3 files I get a .ds store file in each directory it looks in, and resource copies of each song.
I'm not sure why you think not doing this would lead to the files being destroyed if it was zipped. Deleting the Mac Spore with Finder Cleaner has no negative effects.

besson3c · Apr 3, 2007, 06:42 PM

Originally Posted by Chuckit

What on earth is "anti-social" about including Mac-specific data in a MACOSX folder in zips created by the Finder? Would you prefer it if zipping files had the potential to destroy them?

What is in this metadata that would destroy these files?

To the original poster, you could try zipping or tarring the files via the command line.

peeb · Apr 3, 2007, 06:45 PM

From the Finder Cleaner site:
"Product Description:
FinderCleaner cleans hidden files the Finder creates. These files can be annoying in mixed OS environments or they might even cause some deveices like mp3 player not to function correctly.
Usefull for usb sticks or mp3 players for example.
FinderCleaner cleans the following items:
* .DS_Store files
* Resource forks
* FBC files
* .Trashes
FinderCleaner can also eject a volume in a clean way so no new mess is being created by the Finder."

Chuckit · 08:51 PM

Originally Posted by peeb

It's anti-social because if a Mac accesses a shared drive on a network it leaves a lot of meta-data files all over the place that are visible to Windows machines. There should be a way to track that without proliferations of files in every directory that the Mac accesses. It's most annoying to Windows users. When I use my Apple to manage music on my iRiver, for example, as well as the .mp3 files I get a .ds store file in each directory it looks in, and resource copies of each song.
I'm not sure why you think not doing this would lead to the files being destroyed if it was zipped. Deleting the Mac Spore with Finder Cleaner has no negative effects.

Yes, but .DS_Store not what this thread is about. This thread is about the MACOSX folder in zips, and removing that is what can muck things up.

Originally Posted by besson3c

What is in this metadata that would destroy these files?

Resource forks. They're essential to some Mac filetypes. Legacy fonts in particular store all their important data in the resource fork, if I recall, so zipping just the data fork will hose them.

peeb · Apr 3, 2007, 09:09 PM

Ahhh. OK - I was confusing the resource forks with the junk that OSX litters everywhere!

Thinine · Apr 3, 2007, 09:17 PM

Check macupdate.com for something like DropZip. There are any number of alternative compression solutions for OS X.

besson3c · Apr 3, 2007, 10:50 PM

Originally Posted by Chuckit

Yes, but .DS_Store not what this thread is about. This thread is about the MACOSX folder in zips, and removing that is what can muck things up.

Resource forks. They're essential to some Mac filetypes. Legacy fonts in particular store all their important data in the resource fork, if I recall, so zipping just the data fork will hose them.

Resource forks suck balls, I hate them with a passion.

I've given up on caring about them. I just want my data safe, I don't care about maintaining integrity to application files, I'd rather just reinstall the app. There is such a little need for worrying about resource fork data that I can see now, there should be some way to not pass on crap metadata to people who can't use this information and don't care about it.

I'm sick of .Appledouble crap, .DS_Store crap, this crap, more crap... just nuke all of this crap and give me my data!

</End of unfocused rant>

besson3c · Apr 3, 2007, 10:54 PM

I hope that now that Tiger supports xattr (an open standard for storing metadata), we can do away with all of this hacky crap.

TETENAL · Apr 4, 2007, 12:02 AM

It's not a question of what Tiger supports, it's a question of what the ZIP-format supports. And for all that is not supported in ZIP there is the MACOSX folder as a workaround. It doesn't cause mental overlaod to ignore a folder called MACOSX when you are using Windows. Anyway, if you want to make sure, use another program to create the ZIP archive like StuffIt.

besson3c · Apr 4, 2007, 12:37 AM

Originally Posted by TETENAL

It's not a question of what Tiger supports, it's a question of what the ZIP-format supports. And for all that is not supported in ZIP there is the MACOSX folder as a workaround. It doesn't cause mental overlaod to ignore a folder called MACOSX when you are using Windows. Anyway, if you want to make sure, use another program to create the ZIP archive like StuffIt.

With xattr (extended attributes) these attributes are actually attached to the file, and any OS that includes a filesystem with xattr support (as all Unixes do, and XP has support for in a similar way to how OS X litters extra files - see Extended file attributes - Wikipedia, the free encyclopedia) will recognize these attributes without having to create invisible files. Because this is happening at the file system level, as long as tools like Unix zip compile and work on your platform, they should be fair game as far as dealing with these extended attributes, AFAIK.

For years the Mac has required special treatment of its files. It has always been a pain transferring files to and from other file systems, particularly back in the OS 9 days. When you are using a backup tool, it has had to be savvy about this metadata, and this has lead to Apple having to provide their own modified version of rsync, for instance. A paln in the butt, especially since Apple's rsync has been reported as being buggy for some users. In many Unix-centric environments, administrators live and breath rsync, so although it is not a standard part of Mac user vocabulary it is an important tool nonetheless (and I'd be willing to bet that many OS X GUI apps use it). Rsync is one example of where things can become hairy.

TETENAL · Apr 4, 2007, 01:38 AM

Originally Posted by besson3c

With xattr (extended attributes) these attributes are actually attached to the file, and any OS that includes a filesystem with xattr support will recognize these attributes without having to create invisible files.

All nice and well, but ZIP doesn't support extended attributes. Since there are no provisions in the ZIP format to store those attributes the OS has to do it within the additional MACOSX folder. Not the most beautiful solution, but better than corrupting files in something that is supposed to be used for archives.

angelmb · Apr 4, 2007, 02:39 AM

Originally Posted by Thinine

Check macupdate.com for something like DropZip. There are any number of alternative compression solutions for OS X.

BetterZip does wonders, not free though…

BetterZip 1.4.2 - MacUpdate

Chuckit · Apr 4, 2007, 02:50 AM

Originally Posted by besson3c

With xattr (extended attributes) these attributes are actually attached to the file, and any OS that includes a filesystem with xattr support (as all Unixes do, and XP has support for in a similar way to how OS X litters extra files - see Extended file attributes - Wikipedia, the free encyclopedia) will recognize these attributes without having to create invisible files. Because this is happening at the file system level, as long as tools like Unix zip compile and work on your platform, they should be fair game as far as dealing with these extended attributes, AFAIK.

As far as I'm aware, the zipfile itself can have xattrs, but the format does not archive files' extended attributes. (I just had a look at Zlib and don't see any xattr support.) The lack of support for arbitrary metadata is why Apple had to implement Mac OS X's extended attributes with a special folder.

Also note, OS X does include xattr support.

besson3c · Apr 4, 2007, 07:53 AM

Originally Posted by TETENAL

All nice and well, but ZIP doesn't support extended attributes. Since there are no provisions in the ZIP format to store those attributes the OS has to do it within the additional MACOSX folder. Not the most beautiful solution, but better than corrupting files in something that is supposed to be used for archives.

It's not a question of zip itself supporting xattr, because like I said, AFAIK this occurs at the filesystem level. I believe Apple's zip implementation and the scattering of the MACOSX folder is something Apple specifically designed in for compatibility purposes.

TETENAL · Apr 4, 2007, 07:59 AM

A ZIP is different than a disk image. There is no "file system" inside, so what happens on the file system level is irrelevant. What is relevant is what the container format of ZIP supports. And what that container format doesn't support must be stuck in the MACOSX folder.

besson3c · Apr 4, 2007, 08:42 AM

You might be right, I'm not certain... I'm still inclined to think that ZIP or any other compression/archive format does not have to do anything special to support these file system attributes. When you copy a file, it's file system pointers and associations stay intact (or can, if you choose to preserve these attributes). Unix zip works by altering the data contained within a file, while OS X zip first makes a copy of the file and then applies its zip algorithm. The xattr attributes are not actual data that is somehow attached to the file, they are file system attributes. They are a separate file system database with pointers to the associated files.

At least, that is my understanding of how this works.

TETENAL · Apr 4, 2007, 09:04 AM

Are you ignoring that you can ZIP multiple files into a single archive? The process of zipping consists of two things : a) compressing individual files and b) packing them into a single container. If the container format doesn't have provisions for extended attributes (and it doesn't since it is decades old) then they can not be stored.

besson3c · Apr 4, 2007, 09:33 AM

I guess that makes sense...

Of course, Apple may have designed xattr support into their particular implementation of ZIP, but that doesn't do anybody any good once those files are written to NTFS. I wonder if there is any RFC proposals in place to extend ZIP, if not so already, for Unix/Linux?

Hal Itosis · Apr 4, 2007, 05:41 PM

Originally Posted by besson3c

I'm sick of .DS_Store crap
</End of unfocused rant>

KBdoc #301711: "How to prevent .DS_Store file creation over network connections"

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Tiger only I think.

besson3c · Apr 4, 2007, 06:01 PM

Awesome tip! Thanks...

peeb · Apr 4, 2007, 09:56 PM

If only it worked for all external drives - I'm embarrassed when a windows user puts a thumbdrive in my mac to take a file, and the mac leaves a load of junk on it too.