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

Quickly remove resource forks System
I went a bit nuts trying to find a resource fork remover to run under OS X. I found a couple of oldies that would run under Classic, but they were not very reliable. I then remembered how UNIX is generally "HFS unfriendly." I went into a terminal Window and did a man cp, which very nicely told me a quick way to clean up a folder of HTML and pictures that were bound for the web. I then used the Terminal to cd my way to the folder above the folder containing the files, and then ran this command:
cp -p -R LobsterconOld LobsterconNew
the -p option tries to preserve as much of the date, time, and permissions as possible; the -R option is the usual "do recursion" flag ... and off it went doing 200+ files in five folders totalling 30 MB or so on a 700 MHz iBook in a few seconds. When I was done, I simply trashed the old folder once I was sure the result was OK (which it was).

[robg adds: The usual resource fork disclaimer applies: make sure you're doing this on the correct folder, as if you're not, it's a great way to kill any applications that use the resource fork to hold key portions of the program!]
    •    
  • Currently 3.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (2 votes cast)
 
[15,080 views]  

Quickly remove resource forks | 14 comments | Create New Account
Click here to return to the 'Quickly remove resource forks' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Quickly remove resource forks
Authored by: bostmass on Jul 21, '03 09:54:21AM

There is an awesome contextual menu that does this called Grim Reaper from Abracode. You can download it at http://free.abracode.com/cmworkshop/



[ Reply to This | # ]
Quickly remove resource forks
Authored by: norz on Apr 10, '11 11:40:04AM

GrimRipperCM: http://free.abracode.com/cmworkshop/grim_ripper.html



[ Reply to This | # ]
Why? seems like a bad idea
Authored by: SOX on Jul 21, '03 10:58:38AM

I'm curious, Why do you want to do this? seems ill advised. this loses all the meta infromation about the files, like their icons, creator app, etc...



[ Reply to This | # ]
Why? seems like a bad idea
Authored by: MacDork on Jul 21, '03 12:44:14PM

When you email a document to PC users, their machines have *no idea* what to do w/ a resource fork.



[ Reply to This | # ]
Why? seems like a bad idea
Authored by: bluehz on Jul 21, '03 01:05:32PM

MacDork - people often use this technique to slim down filesizes on images used on web pages. The mac image files have a small bit of overhead size 2-8k or so for each image for ther resources. They are useless in web applications - so why not trim the fat. I supposed there may be other uses for this technique too, but thats probably the most common I suspect.



[ Reply to This | # ]
Why? seems like a bad idea
Authored by: kikjou on Jul 21, '03 01:17:46PM

There are a few reasons why you may want to strip the resource fork.
(1) Web mail: Yahoo and others will display two files with the same name if you send an attached Word document. The user will be unable to open either of them and they will whine to you about your badly formatted email (while in reality Yahoo is doing a bad job reading AppleDouble-encoded attachments).
(2) Space saver: Thumbnails (icons) are cute but they add a few bytes to your file. Just have a folder with hundreds GIFs of 1 kByte or less each (such as those used for web pages) and now create icons for all of them. You have just used 2-3 times more hard disk space. On another note: MacOS X now creates thumbnails on the fly by reading the data fork.
(3) About loss of meta information: yes, you will lose the type and creator (although they are not stored in the resource fork but rather in the HFS directory structure. But, again, if you have MacOSX configured right and if you use those aweful three-letter suffixes, you should be more than fine. You will also lose other meta information such as the hidden bit and the hide-extension bit.
So, if you do not use file suffixes (extensions) and if you love your thumbnails (icons), don't mess with the cp command.



[ Reply to This | # ]
Quickly remove resource forks
Authored by: mj on Jul 21, '03 05:15:57PM

You can empty the resource fork of a file a_file by doing:

echo -n > a_file/rsrc

and this should preserve the other Mac specific info. I don't think there's a difference between removing the resource fork and emptying it. Using this in a shell loop over a globbed file list would let you use it on multiple files and nested directories.

Michael



[ Reply to This | # ]
Should be a hint on it's own!
Authored by: discordantus on Jul 22, '03 01:17:34AM

This one is really a hint in it's own right... I had no idea that you could access the resource fork that way!

OTOH, emptying the resource fork is not the same as deleting it, I think. I'm basing this on the behavior of ResEdit; when you open a file, sometimes it says "This file does not have a resource fork. opening it will create one"... and then it creates an empty resource fork. I would assume based on that that there is some amount of overhead consumed by the resource fork all by itself, or every file would automagickly have one.



[ Reply to This | # ]
Should be a hint on it's own!
Authored by: mj on Jul 22, '03 01:40:53PM
It turns out Rob already has posted a hint about this here, and there's an interested comment at the bottom about using the '..namedfork' route to get at any named fork.

You're right about there being some overhead with a resource fork. When you 'create' a resource fork with ResEdit, it adds a header to the fork. But every file does automatically have a resource fork that you can read from and write to, it just normally has length 0, i.e. no header info.

Michael

[ Reply to This | # ]

yes, this is the preferred way to do it
Authored by: garbanzito on Aug 06, '03 11:25:48PM
... since all it changes is the resource fork.. approaches with cp etc. are more cumbersome, and can lose other info that doesn't take extra space or complicate file transfers.. they will even fail under certain circumstances (such as too little space, permissions problems ...)

if you are writing this into a script, or reading this years later, you'll want to use the non-deprecated form "/..namedfork/rsrc".. another way to express this is:

cat /dev/null >filename/..namedfork/rsrc

and yes, emptying a resource fork is all that's needed (technically, you can never really delete a resource fork on HFS+)

[ Reply to This | # ]

Quickly remove resource forks
Authored by: bluehz on Jul 22, '03 10:06:14AM
This small script will remove the resource forks and retain the original names. USE WITH CAUTION - as with any automated rm commands - this one has the potention to wreak havoc. There is a test command you can use with it to display what WOULD be changed. Use the "-v" option - rm-rsrc . -v

#!/bin/sh

# Filename: rm-rsrc
# Remove resource forks
# Usage: rm-rsrc filename/dirname [-v]
#
# Single-file example:
#
#   rm-rsrc filename
#
# Complete contents of directory
#
#   cd <dir>
#   rm-rsrc .
#
# Test only - no files modified
#
#   rm -rsrc filename -v

for cfile in `ls $1`;
   do
   if [ $2 = "" ]; then
      cp $cfile $cfile.***tmp***
      mv $cfile.***tmp*** $cfile
   else if [ $2 = "-v" ]; then
      echo $cfile
   fi
   fi 
   done


[ Reply to This | # ]
don't use that shell script
Authored by: lukec on Jul 23, '03 02:25:02AM

A few suggestions.

Renaming a file to $name.*** is a bad idea. Unless you've somehow explicitly disabled command substitution this will likely not work. Type echo * in that same directory and see what you get. That will be substituted for '*'.

You should also look at replacing your 'ls' command with 'find . -type f'. This will enable recursive functionality.

You probably don't want to strip your resource forks in place. So using tar in a situation like this would be nothing short of brilliant. Straight from any non-apple manpage for tar:

tar -cf - -C srcdir . | tar xpf - -C destdir

I know we're all eager to share what we know, but you should always test a shell script before you post it. Those who would use it, probably can't debug it.

Luke



[ Reply to This | # ]
don't use that shell script
Authored by: bluehz on Jul 23, '03 07:21:56AM

thx for the info lukec - I am definitely no pro when it comes to scripting. Always open to input from those more skilled than me. Heck 80% of everything I have learned scripting has been from here.



[ Reply to This | # ]
don't use that shell script
Authored by: bluehz on Jul 23, '03 08:26:42AM

... also - I CHECK every script, hint, etc, I post - usually several times, and on more than one machine. The above script was tested, several times and performed acceptably for the purposes it was intended. It may not bethe best scripting in the world, BUT it does work, and I have had no problems with it.

...nevertheless thx



[ Reply to This | # ]