The problem: When copying (writing) a guest XP file into a mapped host shared directory (with write permission) it will change the copied file's time & date to the current one instead of maintaining the original one (as the file was not been modified (just copied).
Have set up probably over a half dozen similar systems and this problem persists.
It really is quite a nuisance as it neuters file syncing functionality, and anything else that depends upon modified date. It occurs only when the copy destination is a shared folder (Vboxsharedfolderfs), regardless of the copy source (NTFS, FAT, Vboxsharedfolderfs, etc) So it seems to be a Vboxsharedfolderfs issue.
Hopefully it can be accorded a higher priority and be resolved.
So far it looks like this is a problem of the Windows guest additions. The Linux guest additions behave quite well regarding the time stamps.
In case it matters, if the file being copied/moved to the shared folder is zero bytes, it retains its' original/correct modified date.
I also see this bug with VBox 3.2.8 r64453, Windows XP Professional guest, up-to-date Ubuntu Lucid host.
Interestingly, the touch program in gnuwin32's coreutils ( http://gnuwin32.sourceforge.net/packages/coreutils.htm) is able to set timestamps. I'm not familiar with gnuwin32's code, but perhaps it is bypassing a broken high-level interface? That would be where this bug lies.
Perhaps Windows Explorer sets only the modified time (which is silently ignored on the host). I do own the files.
This happens only if the Windows program uses the CopyFile() function to copy a file to a shared folder.
The work-around in the FAR manager is to uncheck "Use system copy routine". And the sync / backup program should use SAMBA (\server\ or mapped network drive) instead of the shared folder. It is slower but it works.
Fix in r40532. This fix will be part of the next maintenance release.
Fix included in 4.1.12 (please also update the Guest Additions).