Resource forks and tar
Of course you can also make it automatic by inserting the command into. After having done that, try using tar again and like magic it now prevents tar from backing up those pesky resource fork files. Another type of file that you might also want to exclude from copying is the. This time you can just use the —exclude option of tar for that. Gerry Ilagan is into mobile apps and WordPress development at speeqs. I knew about the old environment variable but had no idea it had changed.
I should just note that while such features have largely gone out of use with Mac OS X, the resource fork's capabilities go far beyond storing file-type information. The resource fork is nothing less than a comprehensive database capable of holding all sorts of information - including icons, pictures, text, programme code, and so on - in a standard format accessible using only standard system routines. In fact, prior to the switch to PowerPC, most programmes consisted entirely of resources, with nothing in their data fork whatsoever.
Sat Jun 18 Thanks, just the thing I was looking for! When you create a tar archive, for example: At least that works with the tar that ships with OS X: Comments Thanks, I was getting really frustrated with this. Cleaning up those ". 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 SOX on Nov 26, '03 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. 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. 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?
- mac mini 2011 dual hard drive;
- Navigate / search?
- american airlines center fleetwood mac tickets.
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 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.
Mac OS X Resource Fork and Command Line Tips
In the future I expect we may see more meta data but lose the resource forks. 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. 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?
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 ". 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. Given all the "be more like Windows" changes in OS X, many of which are frustrating file extensions Resource forks are quite handy, and in fact I'm sad to see them go in OS X.
Some examples. On a PC, or even with data only files in OS X, the file's suffix is the only thing that tells the OS what type of file it is, and what to use to open it. That's fine and dandy for the majority of situations, but I'll give a few examples. I'm a graphic artist, and two of the programs I use all day are Adobe Photoshop and Illustrator.
Mac OS X Resource Fork and Command Line Tips
Both of these applications can save a file in the EPS format, but the files are quite different! Illustrator EPS files are mostly vector information, and opening one of these in Photoshop will cause the file to be rasterized. Photoshop can also save EPS files, but these are basically bitmap raster files wrapped up in a PostScript shell. If you open these in Illustrator, you will see a document with a placed image. If these files had no resource fork, such as when they come from a PC, you have no idea what application created them, you only see "myfile.
Previews and thumbnails are also in the resource fork. This way, double clicking on the file would launch the correct application, even if you have OS X set to use Preview by default for EPS files. So if you know you are going to send a file to a PC user or any OS other than Mac OS saving your image files with no previews will prevent resource files from being sent with the data file. Some Mac files, such as font suitcases, will become damaged with the resource stripped off, since the actual font is in the resource fork. OS X's dfonts are data only. If a file with resource forks needs to be sent it must be stuffed and not zipped unless you are doing this trick, but I think it's much easier to use Stuffit.
Just to clarify: