Error -36

use just delete . .DSStore files. they are resource forks of the .DS_Store files and won't contain a lot of info. I've never seen them myself actually but I don't muck with FAT drives much. if you use dot_clean with the -m option that will delete the resource forks on all the files and that's an overkill. and dot_clean won't be able to merge the resource forks with the files themselves while they are on the FAT drive. you don't want to do that if they don't cause problems when copying. but you might need to run dot_clean on the copies once you copy the stuff to the main drive to merge them with the main files there.


BTW, if deleting . .DSStore works you may have found the source of the problem here. there were a LOT of the posts about people getting error -36 when copying folders from FAT drives and AFAIK, nobody could figure out the reason.

dsstore is generated and used by a mac file system...aka desktop database. They are normally hidden from the user and permissioned only for use by the OS.

-36 is a permissions error - Trying to copy hidden files owned by the OS without proper permission will generate -36.

Mac users rarely run into issues with them until they start working across Mac & Windows OSs.

SRX84X wrote:
thanks for the speedy reply,

and i think all the people that have the error -36, will now be able to solve their problems.

Also, just to clarify when the copy the data such as my music back to my mac drive, i can use the dot_clean to merge the ._filenames?

yes. although most likely it will happen automatically.

also btw what do the ._filenames do ?

they are resource forks of the main files. resource fork of a file contains various metadata of a file such as a custom icon or a bundle bit. FAT file system does not support resource forks so when you copy something from an HFS+ drive to a FAT one the resource fork splits into a ._ file. when you copy it back to an HFS+ volume it should be automatically merged with the file. sometimes that doesn't happen though. you can check using ls -la if it does. if it doesn't you'll need to use dot_clean to merge. but most likely you won't have to.

Thanks

SRX84X wrote:
Thanks for your help and information... i really appreciate it.

you are welcome! you deserve a big thank you on this yourself. as i said, this error caused a lot of grief and AFAIK, you are the first to come up with the fix.

I spent almost 30 minutes on the phone with apple and the technical support couldn't even tell me how to solve the problem. I finally decided to try out my own solution and it worked. 🙂



*To sum it up if anyone has the same problem with error -36, you can try:*
*- To remove all the . .DSStore you can use 'find . -name '. .DSStore' -print -type f -delete' in that directory*
*- Also if on the mac drive with hfs format, use the dot_clean to merge any ._filenames*

amend that to run dot_clean if necessary. most likely it shouldn't be.

*That should solve the -36 errors*

K T wrote:
dsstore is generated and used by a mac file system...aka desktop database. They are normally hidden from the user and permissioned only for use by the OS.

-36 is a permissions error - Trying to copy hidden files owned by the OS without proper permission will generate -36.

Mac users rarely run into issues with them until they start working across Mac & Windows OSs.

KT, will you please stop saying this? error -36 has nothing to do with permissions. you were told this many times.
http://support.apple.com/kb/HT2433?viewlocale=en_US

and there can not possibly be any permissions errors with FAT drives anyway because FAT does not understand permissions.

I finally found this thread.

error -36 has nothing to do with permissions. {...}
http://support.apple.com/kb/HT2433?viewlocale=en_US

There I read:

Type -36 error (I/O Errors (bummers)
This file is having difficulty while either reading from the drive or writing to the drive.
The file may have been improperly written data to the drive or the hard drive or disk
may be damaged. This is almost always indicative of a media error (hard error on the
disk). Sometimes (rarely) it is transient.
Solutions: Try copying the file to another drive. Use a disk recovery software, such as
Disk First Aid to examine the disk. You can try rebooting with all extensions off. Once
in a while this will allow you to read the data. The file in question should be restored
from a backup that was stored on a different disk. Regular backups can reduce the
time to recover from this error.

I don't believe the media error/hard error hypothesis! In my case
( http://discussions.apple.com/message.jspa?messageID=10882048&tstart=0)
"writing to the drive" can't be the problem, because a folder is just read
to be copied to another Mac's Drop Box.
"Reading from the drive" can't also be the reason, because there is *no problem*
to make a copy of the folder on the same hard drive.

What else could it be...?

Maybe the suggestion given at http://db.tidbits.com/article/10743 and http://db.tidbits.com/article/10772 could help (in some cases) but I didn't
try it. I need a simpler solution which I can use every day without cryptic tricks.

I found "Personal Backup" by Intego. I thought that for the purpose to copy
for example the iPhotp Library to another Mac I would have to copy ALL
files (the invisible files too!) and configured "Personal Backup" to perform such
a transfer. Again it didn't work, BUT when I changed the settings to copy
only the visible files it worked perfectly. So do I really need these invisible files
on another Mac? For example when I want to use the copy of the iPhoto Library
on the other Mac, would it work without the invisible files?