Update June 24, 2013
I created a program to fix this problem. You can read about it and download it from here.
Original Post
I just spent all of the previous day fighting a problem with .DS_Store. I use a QNAP NAS for data storage (Linux box with RAID AFP and SAMBA file shares). I also use Retrospect to back up the NAS and move files around from system to system. I normally mount shares using AFP mode.
For some unknown reason, I noticed that it would no longer move files. It also wouldn’t back up all the files. At first I thought it was a permission thing, and I did find a numeric group permission on some of the NAS folders that wouldn’t copy. Because you can't set groups using the web interface, I used a QNAP telnet session to force proper permissions, user and group on the complete share folder but things still would not copy. Retrospect would give errors like this:
While scanning volume Recordings,
Folder /Volumes/Recordings-4/HDTracks Music/Pat Metheny/…ic/Pat Metheny/…,
Scanning incomplete, error 24 ( unknown)
Well, some further work was needed to get to the bottom of this problem. Here is what the Retrospect share mount information looked like:
The File System is reporting Unknown which indicates further confusion. It normally shows Mac OS AppleShare on other similar mounts. I'm not sure what is causing this.
If I opened up a browse dialog on the mount and clicked the expand control for one of the bad folders, it wouldn't show any files inside it:
I opened up a Mac OS X terminal session and went into the mounted share volume. I had to start a super user bash session to do this because the Retrospect engine runs as root and won't let you into any mounted folders as an ordinary user. Here is what the ls command produced (notice the immediate error right after the command):
Even though I can see the files it appears Retrospect gives up due to the error and won't scan the folder. I now used a remote console from the Mac to look at the same folder using the QNAP administrative command line:
Well, this is interesting. We now see the full picture. The .DS_Store files have been renamed to :2eDS_Store (0x2e is the ASCII code for a period). I have no idea what caused this, but the folders with this corrupted name will not copy or back up. I could look into the folders with the Finder and see the files, but Retrospect could not do this. This is what the native EXT4 file system looks like. It also shows the .AppleDouble folders used by the AFP share daemon to store the resource forks for the files.
I later found this link that provided some additional information on this rename problem. It also contained a nice bash script to clean up your file system (use with caution, it also removes other hidden folders needed for proper AFP operation).
To test this as a fix, I manually removed these renamed .DS_Store files:
Now the Mac is not showing the ls command error:
And Retrospect is now happy with this:
And finally, I now know how to avoid this in the future. If the link doesn't work, execute this command in a Mac terminal session to disable use of .DS_Store on network volumes:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
This fix still doesn't solve this problem on removable drives.
Some final notes. I didn't see this problem until I upgraded Retrospect to version 10.0.0 (Mac). This new version adds a feature called Instant Scan and it appears this may have caused the problem. It also seems that mounting the volumes using SAMBA mode will avoid this problem. SAMBA protocol doesn't appear to use Instant Scan, but also won't back up or copy the file resource forks like AFP will. Otherwise, I find Retrospect to be a great product for home or small business backup.