Talk:Resource fork

Merge Fork_(filesystem) with this article?

For me it seems the same? Actually this article concentrate more on mac, the other one on windows. —Preceding unsigned comment added by 194.145.122.175 (talk • contribs) 12:32, May 30, 2007

Introduction paragraph length

Could someone translate the japanese version of this page to English - it is much longer than this.

Listed on translation requests —Home Row Keysplurge 22:39, 21 May 2006 (UTC)

All the information from the Japanese Wikipedia article for resource fork has now been translated and added to the English article. It might require editing to make it consistent (notably, the detail about MFS below), and should probably be given some sort of structure, since at the moment the first section is a series of paragraphs with little connection between them. - Grgcox 16:11, 18 September 2006 (UTC)

I took steps to address the long introduction tag that the article once bore, using WP:LS as a guide. One key fact about "resource forks" that I think is important for any encyclopedic (i.e., useful also for the layperson) summary is that to the average user, these files are invisible (they are flagged invisible) and that users might hear "resource fork" thrown around second hand in conversation but have no idea how to see one. So I took a shot at getting that fact into the summary. burnunit 03:31, 3 January 2007 (UTC)

MFS had it too

The first sentence of the article asserts that the resource fork is something that enxists in HFS and HFS Plus but that's not accurate. It existed from the beginning, in the days of MFS. ;Bear 00:22, 2004 Nov 6 (UTC)

Could you point to a source to back this up? To be clear I'd be willing to bet you are right, I'd just like to see a source to remove all doubt. AlistairMcMillan 08:43, 6 Nov 2004 (UTC)

Inside Macintosh from the very boopseginning, when it was loose-leaf. I ditched my copy years ago as it had become so obsolete. Maybe somebody else has one. ;Bear 22:10, 2004 Nov 6 (UTC)

I hereby do declare and proclaim that I've used MFS disks myself in the olden days and yes, Macintosh files have always had resource forks, even in the MFS days. - Cymydog Naakka 15:23, 8 Nov 2004 (UTC)

Res forks were indeed part of MFS. I have reworded the article - see if you think it's OK. I have stated that the resource fork is a construct of the operating system, though it's implemented in the file system. I think this is reasonable, since conceptually the res fork exists even if the actual implementation is in a separate file, as it is for many OS X apps - to the programmer the separate file still "looks like" the traditional resource fork.Graham 22:32, 8 Nov 2004 (UTC)

cleanup

Hi Graham. You're right, it's by no means a bad article. I've certainly seen—and probably even written—worse. I added the cleanup tag as I think the writing style is a bit uneven, and the article could do with a clearer structure. More a bit of spit and polish than anything else.

It's the sort of thing I'm not very proficient at, so I decided I'd mark the article and come back to it at some other point.

As regards structure, one possible divide I had in mind was to split it into the following sections (in no particular order):

• brief intro
• filesystem and communications (dual forks, streams and attributes in other OSes, binhex et al)
• the original intent and actual use (metadata for some documents, CODE resources, GUI resources etc)
• Limitations (slow, prevented swapping in blocks of code; 'the resource manager is not a database')
• the APIs and other implementations
• the history/future/influence.

What do you think? Cmdrjameson 23:50, 7 February 2006 (UTC)

Looks OK, though possibly reverse (2) and (3) since the need for such a thing will probably provide a better background to the implementation. I agree it's a little uneven, but it can probably be licked into shape with fairly minimal work. Graham 23:55, 7 February 2006 (UTC)

I have here with me a bunch of books that talk about resource forks. In faculty's library there exists I to VI inside macintosh volumes, so in the next week or so i'll post a more detailed description of resource forks. Cariquez 20:00 24 February 2006 (GMT)

Once someone does the cleanup, here are a few more things that could be added:

• to be precise, the Resource Fork is not the database but just a second _file_ (i.e. sequential stream of bytes) attached to the main file. This fork may as well contain random binary data, at least the file system allows that. The database needs to be named differently, e.g. "Resource File" (which appears to be the name used by Apple in many places) or "Macintosh Resource", perhaps?
• speaking of forks: other file systems, e.g. NTFS and HFS Plus, have the concept of multiple forks in a file, meaning that even more metadata can be stored in additional forks.
• Not only MFS, HFS and HFS+, but also UDF and ISO 9660 provide support for storing Macintosh Resource Forks (ask me if you need more info on this, I've done a lot of programming in that area)

Tempel 07:54, 23 March 2006 (UTC)

You're right that the fork is just a file stream, like any other. However, since the Resource Manager assumes ownership of this stream and imposes its own format upon it, it's good enough to talk about the fork and the database as one and the same thing. After all, we are not an apple developer documentation source, but an encyclopedia. I agree it's worth listing the file systems that support it. Graham 09:50, 23 March 2006 (UTC)

Graham: Good points. I agree with you. Tempel 12:13, 28 March 2006 (UTC)

Operating Systems were commonplace

"Unlike most prior microcomputer systems, in which programs directly accessed hardware and were responsible for user interaction and input/output themselves, the Macintosh provided operating system services for many I/O functions, notably the graphical user interface." I think this sentence is misleading. There were a lot of general purpose computers before the Macintosh which had an operating system "for many I/O functions". Few of them had a GUI, that is true, but even today the line between the GUI and the OS is blurry. In addition to being somewhat untrue, saying 'the mac was unique at the time because it had an OS' doesn't have a lot to do with the fact that it's file system had a feature for storing file metadata specially. I mean, we could also say 'the mac was one of the first computers to have a mouse' in this article as well, but it wouldn't be pertinent. Jfm3 15:46, 11 June 2006 (UTC) jfm3

Agreed, that whole paragraph seems superfluous. I attempted to work it out of the article, though I think some of it might be useful. burnunit 02:45, 3 January 2007 (UTC)

I'd go further. The idea that "the Macintosh provided operating system services for many I/O functions, notably the graphical user interface" is totally misleading from a computing point of view. One of the primary purposes of an operating system *always has been*, in fact is defined to be, to provide 'services for many I/O functions'. The Mac, in having an operating system that does this, is simply acknowledging an understanding of a fundamental purpose of any operating system. In suggesting that there is something special about the Mac doing this suggests, erroneously, that such a function is in any way special to a Mac. The first operating systems, decades before Macs, provided exactly such facilities, by definition. (Operating systems also perform other functions to do with general hardware management, including scheduling of CPU resource and memory management).

There always have been programs that directly access hardware since the first computers. When such programs were moved to a distinct layer, along with the other functions mentioned, the notion of 'an operating system' came into existence. —Preceding unsigned comment added by 86.133.14.27 (talk) 00:00, 12 March 2008 (UTC)

Removing this paragraph:

In the out of the box configuration of the Mac OS, resource forks are invisible to users and do not appear with other files displayed by the Finder. However, resource forks can be accessed and edited by the user or programmer of a Macintosh with assorted software tools, including ones distributed free of charge by the manufacturer. Users of other operating systems have varying degrees of compatibility with, and viewing or editing capability over resource fork files.

This makes it sound as if resource forks were separate files instead of a part of the file along with the data fork. I can't think of a way to fix the paragraph so I'm removing it as misleading. - ∅ (∅), 17:15, 18 January 2007 (UTC)

I can see the point of it being mistaken about the particular nuance of it being a part of the file, however the remainder of the paragraph is correct, to wit, resource forks are invisible, but they can be edited. I think there is some relevance to this paragraph in terms of numerous consumers hearing of "resource forks" and coming to wikipedia to find out what they are, since someone may have told them "oh the resource forks didn't transfer" (certainly has been a common problem in multiplatform environments such as office networks) or "the resource fork is corrupted" etc. etc. It is true that they are not separate files, but these qualities of invisibility and editability seem worthwhile to point out. Perhaps we can find a common ground way for the article to address something of interest to non-necessarily-programmer users who might wonder what the resource fork is, while also maintaining accuracy? burnunit 05:08, 31 January 2007 (UTC)

They weren't really invisible any more than data forks were. What was invisible to the user was whether a particular file had a data fork, or a resource fork, or both, or neither (an empty file). For example an executable file or a font/DA suitcase only had a resource fork but no data fork, whereas a (plain) text file only had a data fork, SimpleText files and HyperCard stacks commonly had both (in SimpleText, style information about the plain-text data fork was encoded in a 'styl' resource; in HyperCard, the stack structure itself went in the data fork but extras like XCMDs and sounds and PICT resources for colorization were added in the resource fork). Whether you were dealing with the data fork or the resource fork depended on the application you were using, so neither fork was really any more invisible than the other. - ∅ (∅), 06:33, 31 January 2007 (UTC)

Resource Editors

I believe this page used to link to ResKnife. The link seems to have gone. I didn't put the link there, but I wrote the app. — Nicholas (reply) @ 00:36, 8 February 2007 (UTC)

ditto

Even in 10.4, ditto seems to be preserving the resource fork when cp and mv aren't. (I just tested copying from a local FS to AFS and back.) —Preceding unsigned comment added by Aij (talk • contribs) 22:54, 8 June 2008 (UTC)

Regarding Compatibility problems

"Until the advent of Mac OS X v10.4, the standard UNIX command line utilities in Mac OS X (such as cp and mv) did not respect resource forks. To copy files with resource forks, one had to use ditto or CpMac and MvMac."

Not sure whether you would find this worth including or not, but while cp, tar, rsync and ditto worked properly in 10.4, mv was a different story. While using the "mv" tool to move files from one location on a volume to another location on the same volume worked okay, using "mv" to move a file (with resource fork information and HFS+ metadata) from one volume to another volume would strip the resource fork and HFS+ metadata, thereby corrupting the file and resulting in irreversible data loss. This was reported as Apple Bug ID 4114985, and was eventually fixed in OS X 10.5.--MarkDouma (talk) 01:46, 18 September 2008 (UTC)

Regarding How a resource fork is accessed

"To view the resource fork in the Terminal application. Append "/..namedfork/rsrc" to your command. e.g., take the command "ls -aol IMG_0593.jpg" then append the resource fork viewing suffix "ls -aol IMG_0593.jpg/..namedfork/rsrc" to view the ls -aol command information of the resource fork of file "IMG_0593.jpg""

Note that this method of accessing the resource fork is deprecated and no longer supported in Mac OS X 10.5 (Leopard). If you attempt it with ls, I believe you get a "no such file or directory" error.--MarkDouma (talk) 01:48, 18 September 2008 (UTC)

Windows NTFS always used ADS

The article's comments on NTFS and ADS not being commonly used needs to be re-worded. NTFS and Windows has always stored file comments in ADS. This is one irritating feature seldom documented; if a user puts comments on a file via Properties (and I know many users that do), this data isn't always copied or archived. —Preceding unsigned comment added by Bwieser (talk • contribs) 18:19, 24 November 2009 (UTC)

__macosx

what about the annonying rf in zip files created under maxos10 called "__macosx"

http://floatingsun.net/2007/02/07/whats-with-__macosx-in-zip-files/

--Galantea0 (talk) 07:37, 28 August 2009 (UTC)

fileserver compatibility

Specific examples of fileservers with problems need to be added to this section. Also, claiming that AFP users encode in AppleSingle contradicts the statement that the resource fork is stored natively. Again, specific examples of servers are needed.

OSX Packages?

Hows do 'resource forks' relate to OSX 'packages'? They sound like very similar concepts. —Preceding unsigned comment added by 94.170.118.6 (talk) 00:15, 7 March 2011 (UTC)

Dead Link

The "Description of the Resource File Format" link points to a nonexisting page (http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-99.html). I think the same info is now available at http://developer.apple.com/legacy/mac/library/documentation/mac/pdf/MoreMacintoshToolbox.pdf .