I have occasionally encountered unexpected problems deleting directory trees (using rm -rf in a shell script). Recently, I encountered a similar problem using a third party application that failed to delete a directory tree using Java APIs. In both situations, the problem turned out to be a failure to remove a directory because it was not empty, and the file it contained was a .DS_Store file. This is odd for two reasons:
- The directory was not one I had viewed using Finder, so why was a .DS_Store file created?
- The .DS_store file was not protected, so why wasn't it deleted along with the other files in the directory?
The only explanation I can think of is that the .DS_Store file was created by a background thread, which is possible, but what would a background thread be doing that would cause a .DS_Store file to be created?
It is looking now that deleting a .DS_Store file is unreliable. This is what I did:
find . -name .DS_Store -print ; find . -name .DS_Store -exec rm {} \; ; find . -name .DS_Store -print
The first print statement listed 16 files. The second print statement listed 8 files. That means 8 files were deleted and 8 were not. Hmm... I repeated the deletion step and 4 of the 8 remaining files were deleted. It seems that every other file is deleted???
Unexplained .DS_Store files are still being created. I restarted, did a find, and found 80 new .DS_Store files in the tree that I have been looking at. Could mdsync or backupd do this?
Deleting a file (any file) may generate an FSEvent that triggers a background process to examine the directory or directory tree. If the background process somehow creates .DS_Store files, that would explain the behavior. Spotlight indexing and Time Machine backup come to mind as possible culprits.