If it doesn't delete it with a normal empty trash, Secure Empty Trash won't be any different.I didn't see this mentioned yet, but would using the option "Secure Empty Trash" make a difference?
Not sure if this deletes the resource fork as well as the data fork.
It's got nothing to do with how "smart" Windows is. Windows doesn't use them so it handles them as regular files.It's probably because of the resource forks.
You see, there are some invisible files that the Mac uses for various things (preferences, icons, etc.) that aren't seen when you use the computer normally. However, Windows isn't smart enough to know what resource forks shouldn't be seen, and keeps them visible.
That is simply incorrect. Resource forks are still used in all versions of Mac OS X. A simple example is alias files created by Finder.OS X does not use resource forks (although it does support them for backward compatibility).
They do when the file-system doesn't support multiple forks. Then the resource-fork and Finder metadata are stored in a "._"-prefaced file, adjacent to the associated data-fork file. This is called "AppleDouble":Plus, resource forks are part of a "multi-fork" file. They wouldn't show up as separate files.
You are correct. I should have said "rarely" used. Unlike OS 9 and previous, where resource forks were used extensively, Apple has tried to limit use of resource forks in OS X. I was attempting to simplify things a bit without diving into every possible case initially. Thank you for the correction.That is simply incorrect. Resource forks are still used in all versions of Mac OS X. A simple example is alias files created by Finder.
Again, I agree. I was attempting to find the most likely cause first, and being that .DS_Store files are found everywhere, I figured that was the first place to look. As fewer and fewer programs use resource forks, I determined this was a lesser possibility. It seems most times people see the .DS_Store file, blow it away, and then are surprised when it comes back.There's really no way to know whether the OP's phantom files are related to resource-forks, metadata, or whatever, until we know exactly what the filenames are.