Timestamp for Files in Shared Folder bug

[dedi]

Using Gentoo Guest on a Windows 7 Host.

Shared Folder has full access in Windows, is mounted with default options on the gentoo guest system. When copying files over with "-p preserve" option, all files get the current timestamp instead of the original one. This does not happen to Folders!

Thanks for any suggestions

[disonance]

Hi,
I'm having the same problem with Ubuntu 9.10 host and XP guest, it prevents the option to use file synchronization application between the shared host folder and other guest folders from within the XP-guest.
Does anyone know of any work around?

[disonance]

bug track: Ticket #6473

Ticket #6473 (new defect)

Opened 2 seconds ago
Timestamp for Files write in Shared Folder - bug
Reported by: disonance Assigned to:
Priority: major Component: shared folders
Version: VirtualBox 3.1.4 Keywords: timestamp
Cc: Guest type: Windows
Host type: Linux
Description ¶

Scenario: Host: Ubuntu 9.10 Guest: XP pro

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).

The consequence: It prevents the use of file synchronization application between the shared host folder and other guest folders from within the XP-guest, as a metter of fact any application that depends on the file's timestamp in the shared folder (on the guest side) will seas to work well (i.e make utility, files synchronization ...)

[ar10]

Same problem with Ubuntu 10.04 host and win 7 guest. The target filesystem (in host) is ext3 and mounted with (rw,acl,user_xattr) flags.
Is this problem being given any consideration? It is very serious. Any workaround available?
Using VBox 3.2.8 r64453
Many thanks.

[715291]

I have had this problem for many versions of VirtualBox. It does not seem to ever get fixed. Current system is Fedora 13 w/Windows XP Guest, and VB 3.2.8 r64453.

My workaround is to not use the shared folders, and to share everything using SAMBA. SAMBA performance is not as good as shared folders, but at least it handles the timestamps correctly.

Jim

[David C.]

And the problem still exists in 2013. VB version 4.2.6 r82870 running on RHEL 5.9 using various RHEL 5 and 6 guests.

When I use rsync to synchronize local files to a directory in a shared folder, it always copies everything because the target's timestamps always end up with the time of the copy instead of the original's time.

For now, I'm working around the problem by using rsync's -c (checksum) option, which eliminates the unnecessary file copying, but it's a Pyrrhic victory, since it now has to read all of the source and destination files in order to generate the checksums. I could use the --size-only option, but that seems risky, since a file might change but not change size.

I could also work around the bug using NFS or some other kind of network protocol, but I don't really want to run an NFS server on the host OS, since I'll then have to secure it to prevent access from hosts elsewhere on the LAN.

Maybe I can set up an rsync server in each guest VM and let the host pull files from there. I'll have to give that a try.

Still, I shouldn't have to develop workarounds like this

[dfaurekde]

And the problem still exists in 2019.
What's weird is that I can use "touch" to change the mtime of an existing file. But cp -a says it can't do that. And my own code (KIO) also fails when calling utime(). So why does touch work?
Anyhow, this is clearly something missing in the vboxfs filesystem driver. Does anyone know if a bug report has been submitted about this? Where should one do that, otherwise?

[socratis]

Things have changed drastically since 2010 when this thread was opened. The Shared Folders have had a major rewrite with 6.0.0, you can't be possibly facing the same issue.

Please open a new thread, this one is long dead, that's why it's getting locked.