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
Timestamp for Files in Shared Folder bug
-
- Posts: 2
- Joined: 12. Mar 2010, 12:44
- Primary OS: Ubuntu other
- VBox Version: OSE Debian
- Guest OSses: Winxp
Re: Timestamp for Files in Shared Folder bug
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?
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?
-
- Posts: 2
- Joined: 12. Mar 2010, 12:44
- Primary OS: Ubuntu other
- VBox Version: OSE Debian
- Guest OSses: Winxp
Re: Timestamp for Files in Shared Folder bug
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 ...)
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 ...)
-
- Posts: 1
- Joined: 7. Sep 2010, 20:36
- Primary OS: Ubuntu 8.04
- VBox Version: OSE Debian
- Guest OSses: win 7, winxp
Re: Timestamp for Files in Shared Folder bug
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.
Is this problem being given any consideration? It is very serious. Any workaround available?
Using VBox 3.2.8 r64453
Many thanks.
-
- Posts: 2
- Joined: 13. Feb 2010, 20:58
- Primary OS: Fedora other
- VBox Version: OSE Fedora
- Guest OSses: Windows XP Professional
Re: Timestamp for Files in Shared Folder bug
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
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

-
- Posts: 6
- Joined: 1. Feb 2013, 18:27
- Primary OS: Linux other
- VBox Version: OSE other
- Guest OSses: Linux (RHEL, primarily)
- Location: Vienna, VA, USA
Re: Timestamp for Files in Shared Folder bug
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
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
Re: Timestamp for Files in Shared Folder bug
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?
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?
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: VirtualBox+Oracle ExtPack
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Timestamp for Files in Shared Folder bug
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.
Please open a new thread, this one is long dead, that's why it's getting locked.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.