From: Michael G Schwern Date: 23:24 on 29 Dec 2007 Subject: COPY_EXTENDED_ATTRIBUTES_DISABLE Oh god, how many things are wrong here. Macs have long had extra file meta-data integrated right into the file separate from the data, which is a great idea. Means you don't wedge meaning into things like file extensions and magic #! lines and magic binary bits. You can have an editor store the last point you were editing at right in the file without screwing up the plain text data. The problem is, nobody else does it this way so there's some trouble when shipping files around. This has created all sorts of hatred from the old binhex .hqx file formats to Macs pooping little .DS_Store files all over remote filesystems. As I understand it, a lot of filesystems support forks, just nobody uses them. Anyhow, there's all good fun reading about that here: http://folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unified_Model.txt But we're not here to have fun, we're here to have hate. And wear tiny little ironic birthday hats and eat bitter, bitter cake. Apple has finally gotten around to making it's Unix utilities resource fork aware. So things like cp and mv and rsync all that can move files while retaining the resource fork without having to use bizarre OS X specific things like ditto. This is great and all, but they have a tendency to not document it. And cp and mv tend to operate on just the local filesystem so you're probably copying from Mac to Mac. Finally it's tar's turn. A utility which is generally used to move files *between machines* and thus you lose the happy assumption that you're going to send it to another Mac. Of course you're going to just turn it on without warning. And in true Apple style they did not document the change in the man page, it's just a fun surprise. And how do you turn it off? Easy, just set COPY_EXTENDED_ATTRIBUTES_DISABLE to true. Yay, negative flags! Is there a corresponding switch? No. But that's not good enough. It's not enough to have a long winded, oddly worded, magic flag to turn off broken default behavior. Oh no. You should REPLACE IT in the next version, again quietly and undocumented, with the even more inspired COPYFILE_DISABLE. Still retaining the negative naming scheme, good, nice and hateful. But making up for it's shorter length with a totally misleading name! It's not file copying we're disabling, it's copying those resource forks we're disabling. Bravo, Apple. Bravo. And now I need to break out an OS X specific subclass for MakeMaker.
From: Peter da Silva Date: 01:54 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE On 2007-12-29, at 17:24, Michael G Schwern wrote: > Oh god, how many things are wrong here. Macs have long had extra file > meta-data integrated right into the file separate from the data, > which is a > great idea. It's a hateful idea. Unless everyone does it, and does it the same way, and it's COMPLETELY visible without using magic utilities, it's hateful. If they could make it so that when you listed a file with a resource fork it showed up as "drw-r--r-- .... file" containing "file/rsrc" and "file/data", that would be peachy, but no. They go halfway there... you can open file/.rsrc... but you can't tell if there's a .rsrc there, without hateful magic. Apple has been moving away from this, using directories instead of files, which is completely equivalent (there's no technical difference between a directory containing two files and a file containing two forks (see above), except you need magic OS-specific code to enumerate the forks, and the code is DIFFERENT for Mac OS 9, OS X, BeOS, and NTFS. And don't get me started on OS/1100. Even Spotlight uses the file metadata as a cache or index only, and the actual spotlight database is stored in a regular file. Which is as it should be. Metadata about a file outside the file is hateful, even if it's just the one bit of metadata that UNIX needs (the execute bit) it causes pain. The more Apple mucks it up, the more people will quit trying to stuff crap in there, and the more we'll get back to a sane flat file. Sometimes hate is nothing but tough love.
From: Michael G Schwern Date: 02:43 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE Peter da Silva wrote: > And don't get me started on OS/1100. Oooh, a whole operating system I've never even heard of! Pray tell, what new hates await us? Please, do go on.
From: Peter da Silva Date: 14:28 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE > Oooh, a whole operating system I've never even heard of! Pray > tell, what new > hates await us? OS/1100, AKA Exec, OS/2200, Exec/8, is the OS on the Univac/Sperry/ Unisys 1100 mainframe. The file system consists of fixed-sized files containing variable-sized elements of four different types. Files may have a read password or a write password, and elements may have multiple versions. A file name may have a reel number or access locator, an f-cycle (version), and an account qualifier. The full syntax, from my memory, is (reel)qualifier*filename(f-cycle)/rkey/ wkey.element/version. But I think I've left some details out. It's religiously line oriented. Commands start with "@", immediate commands start with "@@". Immediate commands really are acted upon immediately: entering the line "@@Q" is equivalent to an interrupt. There's no garbage collections, you have to periodically compact a file with "@COPY,P", and frequently need to enter a utility "FURPUR" (which stands for, IIRC, file utility routine program utility routine). Between the funky file system, the card-punch style command line, the 36-bit word size, and the 1s-complement arithmetic, you'll understand why their largest remaining customer is rumored to be the IRS.
From: Tony Finch Date: 18:39 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE On Sat, 29 Dec 2007, Peter da Silva wrote: > > DIFFERENT for Mac OS 9, OS X, BeOS, and NTFS. I doubt that Solaris, BSD, and Linux extended attributes work the same way either. Tony.
From: Peter da Silva Date: 18:55 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE On 2007-12-30, at 12:39, Tony Finch wrote: > On Sat, 29 Dec 2007, Peter da Silva wrote: >> DIFFERENT for Mac OS 9, OS X, BeOS, and NTFS. > > I doubt that Solaris, BSD, and Linux extended attributes work the > same way > either. Apple, Be, and Microsoft are the ones that have made a big deal out of doing something with them. Though I don't think Microsoft has actually followed through. Which is refreshingly non-hateful of them.
From: Steff Date: 19:10 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE Peter da Silva wrote: > > Apple, Be, and Microsoft are the ones that have made a big deal out of > doing something with them. > > Though I don't think Microsoft has actually followed through. > > Which is refreshingly non-hateful of them. Mind you, I don't think I've ever seen a legitimate piece of software make use of the "alternate data stream" feature of NTFS which many pieces of malware use(d to use) to conceal themselves. I'm struggling to think of anything more hateful than a major piece of OS functionality which is exclusively of use to black hats. S
From: Peter da Silva Date: 19:32 on 30 Dec 2007 Subject: Re: COPY_EXTENDED_ATTRIBUTES_DISABLE On 2007-12-30, at 13:10, Steff wrote: > Mind you, I don't think I've ever seen a legitimate piece of > software make use of the "alternate data stream" feature of NTFS > which many pieces of malware use(d to use) to conceal themselves. That's because they didn't hack an emulation of it into FAT32, and too many laptops need to be FAT32 for various hateful reasons. > I'm struggling to think of anything more hateful than a major piece > of OS functionality which is exclusively of use to black hats. One that's useful to black hats and ALSO necessary for some other purpose so you can't disable it or otherwise treat anything using it as hostile. :p Peter da Silva peter@xxxxxxx.xxx
Generated at 10:26 on 16 Apr 2008 by mariachi