Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Strip creator info from files using the Terminal UNIX
I had a folder of html files that were stuck opening using Netscape all the time no matter what was set as my default browser. Apparently the OS 9 style Creator tags were all set in them. I wanted the files to open using my default browser (which is now Chimera). One can select them all and then use the Finder's Get Info to change the opening application, but that would make them permanently open in Chimera. I really wanted to get rid of any special application to open with and have them track whatever browser is my default at the time.

Knowing that all I wanted was the data forks of the files and not the other meta-info, I used the Terminal to copy (cp) all the files to a new folder. cp being a UNIX-born command, it will copy only the data forks. What this does is strip off any resource forks and meta-data. Now the new files use whatever is set as my default browser.

Be very careful though! Only do this to files that you really know you only want the data forks. Otherwise you will wind up with unopenable empty files (like the one FileMaker database file I had in that directory...).

I think there are other hints and GUI tools to strip extra forks. But using the command line allows you to leverage all the power of complex search patterns and such that can generally only be done via CLI (assuming you are a regexp and find geek like myself ;-).

[Editor's note: You can also use this technique to reduce the filesize of image files that will be uploaded to the web. Just 'cp' them from one spot to another before uploading...]
    •    
  • Currently 2.50 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[8,749 views]  

Strip creator info from files using the Terminal | 7 comments | Create New Account
Click here to return to the 'Strip creator info from files using the Terminal' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Developer Tools: SetFile
Authored by: sardu_mac on Jan 03, '03 11:03:40AM
manpage: http://www.hmug.org/man/1/SetFile.html SetFile in "/Developer/Tools" can set type/creator on files. There are several handy programs in that directory for people looking for Terminal-based solutions to similar problems. Accessing a resource fork (to copy/delete/whatever) is simple, add "/rsrc" onto the end of the file path in the Terminal: % ls -l Finder -rwxrwxrwx 1 user unknown 1914636 May 29 2001 Finder % ls -l Finder/rsrc -rwxrwxrwx 1 user unknown 524729 May 29 2001 Finder/rsrc I think this 'file-as-folder' hack is part of HFS+, not sure.

[ Reply to This | # ]
remove resource fork in place
Authored by: hayne on Jan 03, '03 11:12:30AM

Since the resource fork is stored in a pseudo-file with filename given by appending /..namedfork/rsrc to the original filename, the following alias can be used to remove the resource fork from the original file (without making a new copy as in the hint):

alias rmrsrc 'cp /dev/null \!:1/..namedfork/rsrc'

Sample usage:
foreach file (*.gif)
rmrsrc $file
end



[ Reply to This | # ]
resource fork docs
Authored by: sardu_mac on Jan 03, '03 11:23:34AM
Reference to Apple's (brief) documentation on the "/..namedfork/rsrc" trick: Inside Mac OS X: Performance - Using Pathnames

[ Reply to This | # ]
more explanation
Authored by: hayne on Jan 03, '03 11:38:02AM

I realized I should explain how this works.
The file /dev/null is an empty file which comes standard with all UNIX installations.
(That's simplifying a bit but will do for current purposes.)
Copying this empty file onto the resource fork effectively wipes out the resource fork.
It is necessary to do it this way since the OS prevents removal of the resource fork via 'rm'.

\!:1 is the first argument following the name of the alias when it is invoked - i.e. it is the name of the file. E.g. if I do:
rmrsc foo
then \!:1 is "foo"
The resource fork of a file named "foo" can be referred to as foo/..namedfork/rsrc and this is what I use in the above alias.
The data fork of a file named "foo" can be referred to as: foo/..namedfork/data but that is less useful since standard UNIX utilities act on the data fork anyway (which is the point of the original hint).
Note that this more convoluted naming (foo/..namedfork/rsrc) is now the officially recommended way of referring to the resource fork - the use of the simpler foo/rsrc is still supported for backward compatibility.



[ Reply to This | # ]
remove resource fork in place
Authored by: mickeysattler on Dec 22, '10 04:16:41PM
To strip resource fork data in place with one line in the Terminal, I offer this:

find folder-w-resources -type f -name \*.jpg -exec cp /dev/null {}/..namedfork/rsrc \;
This recursively works in a folder in this directory called "folder-w-resources", finding all things within which are *both* files *and* have names ending in ".jpg", and on those things it copies the null device into the file's resource fork, setting it to a zero-length. Tailor as necessary, make backups beforehand, etc.

[ Reply to This | # ]
Cool Contextual Menu version
Authored by: kkthompson on Jan 03, '03 06:43:35PM
I have always used this useful little app (as an alternative to the command line): GrimRipperCM and it's worked very well.

[ Reply to This | # ]
Deleting the rsrc fork is not exactly the same
Authored by: mingking on Jan 04, '03 02:04:10AM
Yes, using the suggestions about stripping the rsrc forks seems to work to get back to using the default application, but it doesn't have exactly the same effect as doing a cp.

If you just any of the suggested rsrc fork stripping techniques, the resource fork is indeed stripped and then the file no longer opens with the old creator. But interestingly, if you do a GetFileInfo on the file afterwards you can see that the 'meta' info is still there - the creator and type info, and even the Custom Icon attribute (as well as any other attributes the file may have.) So the file winds up e.g. still having the Netscape/IE icon or whatever instead of using the icon for the default browser.

Though it seems to basically work, I'm a bit nervous about those solutions. I think it creates a 'confused' state for the system - meta attributes but no rsrc. I would have expected the Finder to continue to use the attributes, but apparently not. I don't understand why that happens.

Thanks for the tips about using the /rsrc syntax, but I think I'll stick with using cp. It seems more definitive and is more complete in removing any vestiges of HFS. Making a copy doesn't bother me - I think it's a bit safer anyway. You never know when you may have selected the wrong source folder/file. (Oh, that's never happened to me ;-)


[ Reply to This | # ]