Talk:Resource fork

From Wikipedia, the free encyclopedia

	This article is part of WikiProject Macintosh. This means that the WikiProject has identified it as an article pertaining to Apple Computer, but is not currently working to improve it. WikiProject Macintosh itself is an attempt to improve, grow, standardize, and attain featured status for Wikipedia's articles related to Apple Macintosh and Apple Inc. We need all your help, so join in today!
???	This article has not yet received a rating on the assessment scale.

This page has been cited as a source by a media organization. See the 2004 press source article for details. The citation is in: "The Terminal in OS X.", Sitepoint, July 15, 2004.

Contents 1 Introduction paragraph length 2 MFS had it too 3 cleanup 4 Operating Systems were commonplace 5 Removing this paragraph: 6 Resource Editors

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)