Hidden file woes...

The "movie.mp4" and "._movie.mp4" are what's called an AppleDouble file pair. The file data is stored in "movie.mp4" and the file metadata is stored in the "resource fork", "._movie.mp4". When read back in, the Mac system knows that the ._movie.mp4 file provides information about the movie.mp4 file, and reconstructs the information it needs. This is completely transparent to you.

You will see AppleDouble files anytime an app on your Mac wants to write resource fork information onto a filesystem that doesn't understand resources forks. Typically you'll see this over NFS to non-Mac NFS servers.

My guess is that your PSP (is that the Playstation portable?) has a filesystem on it that isn't HFS+ or NTFS (same with whatever you're connecting via USB).

You can use this terminal command to get rid of the ._movie.mp4 files with these steps.
1. Open /Applications/Utilities/Terminal.
2. Type: dot_clean -n

3. DON'T press enter yet.
4. Type a space, then drag the PSP's icon into the Terminal window. You'll see some text appear.
Press enter.
When the prompt (looks like: Computername:~ username$) appears, you can quit Terminal, and it'll be all cleaned up.

Note: You'll have to do that every time you sync your PSP, since that just removes them.

Good luck!

Message was edited by: joshz

Message was edited by: joshz

Try posting that command in the [Automator|http://discussions.apple.com/forum.jspa?forumID=1261&start=0] forum, and asking about how you can make a folder action for it to auto-apply it to your PSP.

Well, I wouldn't say that data is "crap". The metadata is supposed to make your computing experience that much better. It's certainly worked for you 😉

There is no way (that I know of) to stop the system from writing these files unfortunately. Some of the other posts in this thread on how to get rid of those files is probably your best bet...

Message was edited by: glsmith

there is no way to do that automatically. as was explained those files are resource forks used by HFS+ and not junk.

I've written an apple script a while back for someone with the same request.
here it is if you want to use it.
paste it into Script Editor and save it as an application. (An automator workflow will work too).
\\

<pre style="
font-family: Monaco, 'Courier New', Courier, monospace;
font-size: 10px;
margin: 0px;
padding: 5px;
border: 1px solid #000000;
width: 720px;
color: #000000;
background-color: #ADD8E6;
overflow: auto;"
title="this text can be pasted into the Script Editor">
on open some_items
repeat with this_item in some_items
try
set ppath to quoted form of (POSIX path of this_item)
do shell script "dot_clean --keep=dotbar " & ppath
do shell script "diskutil eject " & ppath & ">dev/null&"

end try
end repeat
end open</pre>

\\
when you want to eject your thumb drive drop the drive onto the application icon.

It will delete all the . files and eject the drive.

I guess the other option you have, which may be less work for you in the long run, is to simply use a copy tool that allows you to not copy resource fork information if you don't want/need them. For example, the "ditto" command has a --norsrc option that does just that.

You'd have to do your copying from the command line rather than the Finder, but I suppose you could make some kind of Automator script or AppleScript script accessible via the GUI that runs ditto under the hood...

The only reason there are hidden files is because your filesystem can't handle the metadata. Those dot files don't exist in your Mac directories, or on any HFS+ filesystem. Also, afaik, Linux doesn't even have the concept of "resource forks", so I'm not sure what you're referring to. Extended attributes, yes, but not forks.

If you are copying data to your PSP (rather than having an application write data directly to the PSP), then just use the CLI to copy only the data fork...

So you'd rather have decreased functionality in favor of not writing dot files to filesystems that don't understand HFS+ metadata? Personally I think the use of AppleDouble is a rather elegant way to maintain a consistent user experience across a wide range of filesystem types. But then I'm also of the opinion that the CLI is usually a faster way to get done what I want to get done, so I guess to each his own...

I was speaking in a general way, not for you specifically. Jeez.