Files in the virtualbox share show wrong timestamp

@susejunky project configuration and all the compile flags used in the various macros is always the likely issue. When compiling locally, you have to explicitly add…

Considering the fact, that the locally build works and the OBS doesn’t this sounds to me like the problem is with the OBS way of building. One more reason to contact the OBS mailinglist. Or even open a bugreport for OBS?

I found this thread where a workaround is described. I have not tested it yet but will report back here as soon as I have.

PS
@larryr : It would have been nice if you had posted your findings here as well.

I tested the proposed workaround. It did not work for me:

on the host:

> ls -la /home/USER_HOST/VM_Data/Open*.*
-rw-r--r-- 1 USER_HOST users 40749 Mar  3  2023 /home/USER_HOST/VM_Data/Opensuse_beer_label.jpg
>

the same file in the guest:

> ls -la /home/USER_GUEST/VM_share/Open*.*
-rwxrwx--- 1 root vboxsf 40749 Apr  3 09:43 /home/USER_GUEST/VM_share/Opensuse_beer_label.jpg
>

There were errors when building the modules for kernel 6.8.1-1-default in the guest (openSUSE Tumbleweed 20240329).

see Details on paste.opensuse.org

The issue, and we will use a file on a Window 10 share that is mounted on my Linux Guest (with Windows 10 host) by VirtualBox as an example:

michael@Kubuntu-VM:/media/J$ stat /media/sf_J_DRIVE/build-vim.sh # Note: `/media/J` is just a symlink to `/media/sf_J_DRIVE` the actual mount point:
  File: /media/sf_J_DRIVE/build-vim.sh
  Size: 4952            Blocks: 128        IO Block: 1048576 regular file
Device: 0,56    Inode: 72591       Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 1969-12-31 18:00:00.000000000 -0600
Modify: 1969-12-31 18:00:00.000000000 -0600
Change: 2023-03-27 19:27:39.989683700 -0500
 Birth: 2023-03-27 19:27:39.989683700 -0500

Running the mount command with regard to the guest mount of that share shows us:

J_DRIVE on /media/sf_J_DRIVE type vboxsf (rw,nodev,relatime,iocharset=utf8,uid=0,gid=999,dmode=0770,fmode=0770,tag=VBoxAutomounter)

Additional notes:

  • Access time updates have been disabled on the Windows 10 host (but the file does have a valid access time, as I will show shortly).
  • Notice that the modify time appears to be, in effect, 0 (i.e., right at the epoch). Also, the TZ offset is showing incorrectly as -0600 when it should be -0500 for my timezone (CDT), as is the case for the seemingly correct timestamps.
  • The date command on the Linux guest tells us that the time and timezone are correct and match those of the host:
michael@Kubuntu-VM:/media/J$ date
Fri Apr  5 06:00:37 PM CDT 2024

and then several seconds later on the Windows host:

J:\>date
The current date is: Fri 04/05/2024
Enter the new date: (mm-dd-yy)

J:\>time
The current time is: 18:01:33.88
Enter the new time:
Also, using Cygwin64 on the Windows host:
J:\>c:\cygwin64\bin\date
Fri Apr  5 18:02:24 CDT 2024

I dug deeper into this and here is what is happening:
The Windows file Change Time is being placed into the Modified Time as viewed from the Linux Guest on the mount and the actual Modified Time for the Windows share file is discarded. The Linux guest is also showing an erroneously unset Modified Time as: 1969-12-31 18:00:00.000000000 -0600.

Here is how the file time info looks from the Windows Host perspective, after I did some programming to get the Change Time which is not easy to come by on Windows and note that -05:00 is correct for the CDT time zone:

Item           : J:\build-vim.sh
CreationTime   : 2023-03-27T19:27:39.9896837-05:00
LastAccessTime : 2023-03-27T19:27:39.9896837-05:00
LastWriteTime  : 2023-03-27T19:27:40.0328607-05:00
ChangeTime     : 2023-03-27T19:27:39.9896837-05:00
FileAttributes : 128

again compare and contrast with the stat from the Linux Guest side:

  File: /media/sf_J_DRIVE/build-vim.sh
  Size: 4952            Blocks: 128        IO Block: 1048576 regular file
Device: 0,56    Inode: 72591       Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 1969-12-31 18:00:00.000000000 -0600
Modify: 1969-12-31 18:00:00.000000000 -0600
Change: 2023-03-27 19:27:39.989683700 -0500
 Birth: 2023-03-27 19:27:39.989683700 -0500

Additional info about my setup:
Virtual Box: 7.0.15 latest Developer Build (doesn’t matter, 7.0.14 has same issue)
Host: Windows 10 (10.0.19045 with latest updates)
Guest: Ubuntu 23.10
Installed kernel: 6.8.1 , or more specifically:
Linux Kubuntu-VM 6.8.1-060801-generic #202403151937 SMP PREEMPT_DYNAMIC Fri Mar 15 19:52:22 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Taken as a .deb file straight from Ubuntu’s: Index of /mainline/v6.8.1/amd64

With the corresponding Virtual Box guest additions built for the kernel, installed, and operating (for the vbox 7.0.15 Development Build I am presently running).

So, there you go, another data point with far more info!

Let’s use another file for comparison on the same mount, that has different timestamps for all four of its timestamps, so that there is no ambiguity present:

Windows 10 host:

Item           : J:\other-file.out
CreationTime   : 2020-01-08T11:06:04.7240271-06:00
LastAccessTime : 2021-11-08T14:53:39.4419329-06:00
LastWriteTime  : 2020-01-08T11:06:49.3562341-06:00
ChangeTime     : 2024-04-05T18:18:19.3274703-05:00
FileAttributes : 8224

Here is how it appears on the linux guest and I have no idea why it is showing the times it is showing for the modify/access times (probably left over garbage in memory from some other file?):

michael@Kubuntu-VM:~$ stat /media/sf_J_DRIVE/other-file.out
  File: /media/sf_J_DRIVE/other-file.out
  Size: 466173          Blocks: 1024       IO Block: 1048576 regular file
Device: 0,56    Inode: 75441       Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 2024-04-05 18:11:46.642577408 -0500
Modify: 2024-04-05 18:11:46.642577408 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
 Birth: 2020-01-08 11:06:04.724027100 -0600```

As an additional cross-reference, I created a second (manually mounted) mount of the J_DRIVE share of the Windows 10 host on the linux guest running as a VM, as "$HOME/jshare", but this time with all ttl mount options set to 0 (i.e., cache nothing for file access), which looks as follows from a mount perspective (note the presence of the following options: ttl=0,dcachettl=0,inodettl=0):
J_DRIVE on /home/michael/jshare type vboxsf (rw,nodev,relatime,ttl=0,dcachettl=0,inodettl=0,iocharset=utf8,uid=0,gid=0)

On this manually set up mount with “cache nothing” mount options, running stat on the file shows us:

  File: /home/michael/jshare/other-file.out
  Size: 466173          Blocks: 1024       IO Block: 1048576 regular file
Device: 0,52    Inode: 76041       Links: 1
Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 1969-12-31 18:00:00.000000000 -0600
Modify: 1969-12-31 18:00:00.000000000 -0600
Change: 2024-04-05 18:18:19.327470300 -0500
 Birth: 2020-01-08 11:06:04.724027100 -0600

So I was mistaken, the ChangeTime is being shown correctly, whether FS caching is utilized on the guest side or not, but the Modified (i.e., LastWrite) and LastAccess times are just garbage.

Still more tests of different Linux kernels on the Linux guest with the same version of Virtual Box and guest additions as used previously (7.0.15 Developer Build):

Summary:

Linux Kernel 6.5.0 - Looks good (notice the lack of the creation time with this kernel running, is this a possible clue to the origin of this bug??)
Linux Kernels 6.6.12 and up - All have the issue
#######################
# kernel 6.5.0 - Good #
#######################
michael@Kubuntu-VM:/media/J$ uname -a; stat /media/sf_J_DRIVE/other-file.out
Linux Kubuntu-VM 6.5.0-26-generic #26-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar  5 21:19:28 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
  File: /media/sf_J_DRIVE/other-file.out
  Size: 466173          Blocks: 1024       IO Block: 4096   regular file
Device: 0,57    Inode: 11          Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 2021-11-08 14:53:39.441932900 -0600
Modify: 2020-01-08 11:06:49.356234100 -0600
Change: 2024-04-05 18:18:19.327470300 -0500
 Birth: -

#######################
# kernel 6.6.12 - Bad #
#######################
Linux Kubuntu-VM 6.6.12-060612-generic #202401151837 SMP PREEMPT_DYNAMIC Mon Jan 15 18:49:00 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
  File: /media/sf_J_DRIVE/other-file.out
  Size: 466173          Blocks: 1024       IO Block: 1048576 regular file
Device: 0,56    Inode: 123         Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 2024-04-05 18:56:24.605974612 -0500
Modify: 2024-04-05 18:56:24.605974612 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
 Birth: 2020-01-08 11:06:04.724027100 -0600

#######################
# kernel 6.6.22 - Bad #
#######################
michael@Kubuntu-VM:~$ uname -a; stat /media/sf_J_DRIVE/other-file.out
Linux Kubuntu-VM 6.6.22-060622-generic #202403151938 SMP PREEMPT_DYNAMIC Fri Mar 15 20:29:03 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
  File: /media/sf_J_DRIVE/other-file.out
  Size: 466173          Blocks: 1024       IO Block: 1048576 regular file
Device: 0,55    Inode: 123         Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 2024-04-05 18:51:47.947721793 -0500
Modify: 2024-04-05 18:51:47.947721793 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
 Birth: 2020-01-08 11:06:04.724027100 -0600

#######################
# kernel 6.7.10 - Bad #
#######################
michael@Kubuntu-VM:/media/J$ uname -a; stat /media/sf_J_DRIVE/other-file.out
Linux Kubuntu-VM 6.7.10-060710-generic #202403151538 SMP PREEMPT_DYNAMIC Fri Mar 15 20:14:18 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
  File: /media/sf_J_DRIVE/other-file.out
  Size: 466173          Blocks: 1024       IO Block: 1048576 regular file
Device: 0,55    Inode: 123         Links: 1
Access: (0770/-rwxrwx---)  Uid: (    0/    root)   Gid: (  999/  vboxsf)
Access: 2024-04-05 18:48:09.147629542 -0500
Modify: 2024-04-05 18:48:09.147629542 -0500
Change: 2024-04-05 18:18:19.327470300 -0500
 Birth: 2020-01-08 11:06:04.724027100 -0600