Talk:Resource fork

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Introduction paragraph length

message: "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)
replies: text: 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)
thread_title:  Operating Systems were commonplace 

message: ::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)
replies: text: 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)
replies: text: 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)
thread_title:  Removing this paragraph: 

message: 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)
thread_title:  Resource Editors 

message: 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)
thread_title:  <tt>ditto</tt> 

message: "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)
thread_title:  Regarding Compatibility problems 

message: "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)
thread_title:  Regarding How a resource fork is accessed 

message: 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)
thread_title:  Windows NTFS always used ADS 

message: 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)
thread_title:  __macosx 

message: 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)
thread_title:  OSX Packages? 

message: 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)
thread_title:  Dead Link 

message: 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)
thread_title:  Other operating systems 

message: 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?
⏤ RW Marloe (talk) 19:00, 19 May 2016 (UTC)
thread_title:  .rsrc