Slashdot Mirror
Mac OS X Tiger Accidentally Shipped Early
boarder8925 writes "Engadget reports: 'In many places around the world, Mac fans and Apple distributors received a shipment they weren't quite expecting: Mac OS X 10.4 Tiger arrived at the door a full eight days ahead of schedule for some lucky folks who pre-ordered. Vendors PCMall/MacMall and ClubMac gave pre-order customers a treat by unleashing the OS ahead of schedule, quickly followed up by a 'recall' of the copies from PCMall.'"
At least one other "reseller" has received legal threats, but apparently they think they are immune.
I actually did a diff on the cp man page between panther and tiger. There is no significant different. maybe 4 lines or so changes outlining legacy mode for options -i and such.
/cartman
But there is however a significant changes from panther's cp to tiger's cp.
Apple's website outlines it this way: http://www.apple.com/macosx/features/unix/
HFS+ CLI file commands
Use command-line commands safely on HFS+ files. Utilities such as cp, mv, tar, rsync now use the same standard APIs as Spotlight and access control lists to handle resource forks properly.
This feature... is so huge. It made the upgrade to tiger worth it just by itself. Previously, unix CLI progs such as cp and mv didn't respect certain features of HFS+.
There are flags on HFS such as hidden, bundle, and custom icons. Also (most importantly) cp didn't respect HFS+ resource forks. This broke a lot of stuff when you tried to manage files with cp. You had to use stuff like CpMac and ditto which were piss poor lacking in features. (couldn't handle symlinks. when it got to broken symlinks, it would just die...)
New cp and mv and even rsync (yes!) uses different API now that respects everything and then some. (first class citizens again!)
Even further than just handling HFS+ correctly, this new cp will invoke Spotlight so that spotlight db is correct always no matter how you manage files. This is totally sweet.
Also this API will respect the new ACL functionality in tiger as well.
A few other notable features of Tiger for me are Xcode 2.0, GCC 4.0, new PDF support for forms and encryptions and such.
All that and ACL and the new CLI utils are less hyped but more important to unix users like me than Dashboard (which runs less than spectacularly on G3 600mhz iMac.)
Cornell's law site backs him up; unordered merchandise belongs to the recipient. (Interestingly, I had that link handy because one of the free stuff sites accidentally sent me two iPod shuffles instead of one, and I wanted to know my legal status with regard to the second one.)
You've gotten some pretty good responses, but if you're not using a Mac I fear they are pretty obscure. So let me take a shot at it.
Before MacOS 10, the Apple file system split files into two segments: A data fork, which looked basically like a conventional DOS/Unix file, and a resource fork, which was a sort of mini-database letting you structure your file contents. This was particularly useful in executable programs; the resource fork would contain icons, menu definitions and the like. It would also contain the program that created the file (the "creator code"). When you double-clicked a file, the system would look at the creator code, find the corresponding application and start it up. This was a much slicker system than file extensions because the file could be called anything you wanted and the association with a program was automatic and unchangeable unless you were familiar with system internals.
A program called ResEdit let you change these definitions and you could do things like define different keyboard shortcuts by playing around with the menu definitions.
This was also used by programs to create data file formats. This was very nice, because if those files contained information in standard Apple formats, it could be easily read and modified by ResEdit and similar programs. So the movie files created by Final Cut Pro, for example, had a lot of the information in the resource fork which made debugging and reading these files a lot easier than the alternatives.
MacOS X attempted to get rid of this entirely, because of a significant problem: Resource forks don't exist in the Windows or Unix world, so copying Mac files to other operating systems was a bit of a non-starter. So in MacOS X, we have file extensions, just like in Windows and Unix, instead of creator codes in the resource fork. You can argue until you're blue in the face by saying resource forks are a much more elegant way to deal with the situation, and you'd be right. But at the same time it hardly matters since most people need to exchange data with Windows computers.
Naturally, MacOS X retained support for the resource fork so that applications such as Final Cut Pro could continue to use it. However, they discouraged use of resource forks in future applications.
The problem was that they didn't tell the Unix utilities like cp about the resource fork. Instead, the utilities would copy all the data fork but not the resources. So if you had a Final Cut Pro file using the resource fork, you could cp it to another folder and the file would not work when you tried opening it.
So in Tiger they have fixed this problem, and the resource forks are now retained, so I can feel free to use cp et al to copy all Mac files, including those with resource forks.
This is, of course, a major victory for people like me who like to use the Unix utilities for file management.
D