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

Quickly remove ._ files from Windows' shares UNIX
Here's an easy UNIX command to quickly delete all "._" files written to a mounted Windows drive. These resource files are used by the Mac, but just clutter up the directories on Windows. Here's how to remove them quickly:
  1. Mount the Windows drive.
  2. Open the Terminal application and type:
     % cd /Volumes/Windows_Drive_Name
    % find . -name "._*" -exec rm '{}' \; -print
    This will find all ._* files, delete them, and print to screen a list of all files deleted.
This is pretty drastic, so be sure not to do this on a mounted OS X drive.

[Editor's note: I haven't tested this one myself, but you might want to put a "-i" after the "rm", which will force you to say "yes" to each file that is about to be deleted ... at least until you're certain the command is doing exactly what you want it to do.]
    •    
  • Currently 4.75 / 5
  You rated: 5 / 5 (4 votes cast)
 
[21,147 views]  

Quickly remove ._ files from Windows' shares | 8 comments | Create New Account
Click here to return to the 'Quickly remove ._ files from Windows' shares' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
faster way to rm using find and xargs
Authored by: torkel on Nov 18, '02 05:28:32PM
1) Dry run to see what find finds: find . -name '._*' | more
2) Remove the files: find . -name '._*' | xargs rm
Faster, especially for a large number of files, since xargs starts only one process, whereas -exec starts a new rm process for each file.

[ Reply to This | # ]
Don't need to change directories
Authored by: SeanAhern on Nov 18, '02 07:32:18PM
You don't need to "cd" before running a "find" command. That's what the first argument is for. The previous commands, refactored as one command:
    % find /Volumes/Windows_Drive_Name -name "._*" -exec rm '{}' \; -print


[ Reply to This | # ]
Don't need to change directories
Authored by: mert on Nov 18, '02 09:12:56PM

Change "-exec" to "-ok" for make find ask before allowing the "rm" (or whatever command you wanted run). From the find man page:
"The -ok primary is identical to the -exec primary with the exception that find requests user affirmation for the execution of the utility by printing a message to the terminal and reading a response. If the response is other than ``y'' the command is not executed and the value of the -ok expression is false."



[ Reply to This | # ]
Why not use OS X's Cmd-F ?
Authored by: avonterr on Nov 18, '02 09:23:42PM

Use the OS X Find (Cmd-F) and search for files that start with "." You can then inspect the list of files and delete them from the Find window. You could probably write an AppleScript to run the search by selecting the volume then going to the script menu.



[ Reply to This | # ]
Why not use OS X's Cmd-F ?
Authored by: geohar on Nov 19, '02 04:51:00AM

cmd-F will not display these files as the dot means they are hidden. Besides which, as far as the finder is concerned they are the same file as the one named <x> for the ._<x> filename. There are very good reasons for being wary of removing these. I assume everyone knows what these files are?

If not, let me recap. OSX (and earlier mac OSes) files have two 'forks' a resource fork and a data fork. Both can be very important. The resource fork contains, as well as resources, the creator code and type code for the file. Because HFS can support two forked files directly, you only see one filename. However, may file systems do not support two forks. Therefore, OSX creates a hidden file ._<x> for the filename <x>. The ._<x> file contains the resource fork. The finder, and many of the programming APIs hide this from the user, allowing the fact that there are really two separate files in place. Instead, most operations just see one file with two forks.

OK. So how does this affect you? Well if you blast away the ._<x> files, then all the resoruce forks are gone. You might not care - perhaps. Perhaps the file associations will be screwy. Perhaps (if you have apps or complex files which need resource forks) some stuff wont work. At any rate, you should know what you're doing before you do it. You have been warned.



[ Reply to This | # ]
Noooooooooooooooooo!
Authored by: kennyfett on Nov 20, '02 10:30:49AM

Yeah, I can attest to the 'riskiness' of this action..

I just tested it out last night on a mounted Windows volume I had some backup installer files on. They were all in Stuffit format- I do this only because storing .dmg files and whatnot gets screwed up when copied back onto the Mac...

Anyway, I deleted about 10 or 12 ._ files that accompanied some of those .sit files, and then I decided to test out whethere or not those .sit files would still open.

Well, much to my horror, Stuffit Deluxe (or any OTHER program on my HD) would recognize the file for what it was! Now I have to go back and reload several files- including the iCal and iPhoto installers, which I stuffed and put in storage...

Be warned- this procedure wrecks some types of files!



[ Reply to This | # ]
Problems with some volumes
Authored by: rjbailey on Nov 20, '02 06:01:27PM

Are there known reasons why the \'find\' command will not descend a directory hierarchy? I\'m discovering that 'find [specified directory] -name "._*" -exec rm '{}' \;' ... will not descend into mounted Windows and Linux volumes.



[ Reply to This | # ]
Quickly remove ._ files from Windows' shares
Authored by: mattnevels on Jul 30, '03 11:03:55AM

I wrote an applescript droplet to do this, and it seems to be working great, on all but files that have spaces in their filenames, can someone with a better background in unix shed some light on how I might fix this? Thanks,

Matt

on open fileName
set fullFileName to POSIX path of fileName
do shell script "find " & fullFileName & " -name '._*' | xargs rm"
do shell script "find " & fullFileName & " -name '.DS_Store' | xargs rm"
end tell
display dialog "._* and .DS_Store files in the " & fileName & " path have been removed."
quit
end open

---



[ Reply to This | # ]