Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Easily create HFS-aware PKZIP and unix archives' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Easily create HFS-aware PKZIP and unix archives
Authored by: raider on Nov 26, '03 02:02:40PM
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....

[ Reply to This | # ]
Easily create HFS-aware PKZIP and unix archives
Authored by: SOX on Nov 26, '03 03:08:40PM
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.

[ Reply to This | # ]

Easily create HFS-aware PKZIP and unix archives
Authored by: greed on Nov 26, '03 03:22:19PM

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.

Another thing that gets put in the resource fork is the 'preview' and the 'icon' images. This way, a file can have a custom icon, and you don't have to have a separate file. (Anyone remember .info files on the Amiga?)

I believe the TYPE and CREATOR information is handled in much the same way as the resource forks when dealing with non-HFS-aware programs. On HFS, they are actually attributes of the file, just like creation and modification time, size, and so on.

So forks just give you a way of keeping related 'files' together under one name. It is pretty sloppy on Apple's part to leave the standard BSD utilities unmodified; it would at least be nice if the standard 'ls' command could show type and creator as well. (I despise file extensions for type information, I really liked the MacOS way of making it a full-fledged attribute on the file.)

How do you get a custom icon for something on Windows? For executables and DLLs, it seems they use a special section in the COFF file. Can you even have a custom icon on a data file? It would have to be in a separate file if it was.

That's on data files. For program files, resources would contain everything from the icon sets, to the window and menu definitions, sound samples, and so on. Those are now handled with the ".app" directory format.

Generally, on data files, you should always be able to toss the resource fork without damaging the data (as long as you can get the TYPE some other way.) Mail.app sending the resource fork is just dumb, I had to go through and remove all the resource forks before e-mailing some attachments. Given all the "be more like Windows" changes in OS X, many of which are frustrating (file extensions... yuck), why didn't they suppress the resource fork by default?



[ Reply to This | # ]
Read.
Authored by: Lectrick on Nov 27, '03 01:28:12PM

http://www.macdisk.com/macforken.php3

---
In /dev/null, no one can hear you scream



[ Reply to This | # ]