This is the talk page for discussing improvements to the Resource fork article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
![]() | This article has been mentioned by a media organization:
|
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
Could someone translate the japanese version of this page to English - it is much longer than this.
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)
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):
What do you think? Cmdrjameson 23:50, 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)
"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
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)
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 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)
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)
"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)
"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)
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)
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)
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.
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)
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 . — Preceding unsigned comment added by 82.83.225.119 (talk) 22:00, 5 December 2011 (UTC)
Most operating systems used a binary file containing resources, which is then "tacked onto" the end of an existing program file.
This is innacurate and wrong. Someone with some understanding of the reasoning behind memory segmentation and how it is represented in OS-understood binaries should re-write this.77.94.137.195 (talk) 09:15, 14 April 2015 (UTC)
The .rsrc file is missing. I used a converter (icns2rsrc) a number of years ago to create custom icons for Mac apps and files. It seems according to Stack Overflow (http://stackoverflow.com/tags/rsrc/info) to be a compressed format. Does anyone else have any information about this format?