|
|
Easily create HFS-aware PKZIP and unix archives
Allright, let me start by noting that I am a switcher - as of the release of OSX 10.0.
I have never understood the benefit of resource forks, but have been plagued by the problems caused by them. Mail.App before Panther handled them terribly for cross platform usage (or rather most windows mail applications handled them incorrectly - as AppleDouble is an internet standard - but still it was ALWAYS percieved as my fault for using a "POS Macintrash" - not good for getting people to like or even tolerate Macs...). The common unix commands like cp and mv would kill them, and break some files and programs... And things like this, where they are not supported in the formats that the whole world uses... Ideally I would only like to ever have to interact with a Mac - but realistically, if I want to stay employed, I need to interact with various operating systems, and none of them have resource forks except the Mac. So my question to long time mac users (who I am sure will answer) - Why do we even need them any more? Why not just get rid of them, and not have these problems? What benefits did resource forks provide that warrants keeping them around? Links to sites are appreciated, but I am also interested in personal opinion....
Easily create HFS-aware PKZIP and unix archives
Not an answer to your question but...
Microsoft's longhorn and several Gnu projects are moving in the direction of even more meta data since the user experience will be a file system accessed via data base not a folder hierachy.
The mac metadata and reousrce forks serve distinct rolls. The meta data allows one to know what program created or shoul dopen a file without having to reply on the name extention convention. It also can indicate other things like the fact that the file is a HFS alias (as opposed to a unix link). the resource fork was a neccessary item to assure programs and documents could carry around auxilirary information without having to have multple files. In Mac OSX this is replaced with an equally arbitrary solution. One can create a folder that contains multiple files that all pertain to the document or application. For example the applications now all are designated by the arbitrary addition of .app to their folder name. In the finder they appear as atomic entity rather than as a folder you can (easily) open. What's arbirtary here is the follwoing. When you double click the icon how does the finder know what to do? well it looks inside the folder for a file that obeys a certain naming convention. When you look at the file in the finder how does it know what icon to use? Well again inside the folder a naming convetion is used to tell the finder which is the icon. How do applications egister services with the OS. You got it.... the resource fork was just a different solution to this problem that worked fine. The problem was not that mac made a bad choice, rather the problem was that EVERYONE else (unix, DOS) made a bad choice by not creating a rich enough specification for how to do accomplish all these needs when applications require auxilirary files and yet how to keep the application as an atomic entity. Thus the macs had a hard time mapping their scheme onto these weakling file systems. This was the source of this headache. the headache recurs now mainly as a legacy; pure osx files only have meta data but not resource forks. In the future I expect we may see more meta data but lose the resource forks.
Easily create HFS-aware PKZIP and unix archives
Resource forks on data files are typically used to contain 'state' information. For example, a text editor I used to use would write the current position to the resource fork, so any program that didn't know how to use that resource would just see an ordinary text file in the data fork.
Read.
http://www.macdisk.com/macforken.php3 |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.11 seconds |
|