Sorry!
Only do
Don’t create a new file in the VM.
Ooops, I’m puzzled.
WEGA:~ # cd /media/sf_Ordner
WEGA:/media/sf_Ordner # ls -la
total 0
drwxrwx— 1 root vboxsf 0 Feb 28 08:30 .
drwxr-xr-x 1 root root 18 Feb 27 22:49 …
-rwxrwx— 1 root vboxsf 0 Feb 28 09:35 Neues Textdokument.txt
-rwxrwx— 1 root vboxsf 0 Feb 28 09:34 test.txt
WEGA:/media/sf_Ordner #
Both files are from yesterday, I think, we produce same results.
Yes. I think it is obvious now that the problem is not related to my individual configuration.
If you have a look at your post from yesterday
you can already see that (on the guest) the “.” entry of your shared folder had the timestamp 1. Jan. 1970 which i think is not the date when you created your shared folder.
Thank you very much for your support!
I will create a bug report (and post a reference here).
Just in the case people missed this.
This time stamp corresponds to the Epoch: 1970-01-01 00:00 UTC, which is all zeros. It seems that somewhere zero is filled in in a time stamp field where it should not.
1 Like
I can confirm it happens with Tumbleweed KDE guests but not with GNOME or MATE or XFCE guests.
So I think it is an KDE issue. I think the latest KDE is not seeing permission for the parent directory so it uses epoch date.
Here Ihave to contradict, my tumbleweed vm showing this behaviour is xfce desktop.
The only available DE of my openSUSE Tumbleweed guest is Plasma5 (KDE).
However when I start my guest in run level 3 (so there should be no DE involved?) I still see (by doing ls -la) that the “.”-directory in the virtualbox shared folder has a timestamp 1. Jan. 1970. Many of the other files there do as well have this timestamp and the rest has a timestamp that reflects the start of the VM.
On the host system those files do all have different (correct) timestamps.
And not to forget: Kubuntu does not show this problem (but it uses a slightly older version of Plasma5 and has an older Kernel).
In more testing if host in 7.0.12 and guest is 7.0.14 - the date is wrong on shared folders.
Failed on KDE. Gnome, XFCE and MATE.
In some combos the date is the time of the mount, some it is the some time in the way past.
On my KDE guest, the fime stamp is the current one. Definitely wrong in the guest, but OK in the host other than the file that was copied, which got a new write date and time.
Let’s take into account its probably a btrfs-thing, with 4 timestamps, other systems uses 2 or 3.
georg@vm203:~> touch test.txt
georg@vm203:~> ls -la test.txt
-rw-r–r–. 1 georg georg 0 28. Feb 17:46 test.txt
georg@vm203:~> stat test.txt
Datei: test.txt
Größe: 0 Blöcke: 0 EA Block: 4096 reguläre leere Datei
Gerät: 0/46 Inode: 1579824 Verknüpfungen: 1
Zugriff: (0644/-rw-r–r–) Uid: ( 1000/ georg) Gid: ( 1000/ georg)
Kontext: unconfined_u:object_r:user_home_t:s0
Zugriff: 2024-02-28 17:46:54.406661750 +0100
Modifiziert: 2024-02-28 17:46:54.406661750 +0100
Geändert: 2024-02-28 17:46:54.406661750 +0100
Geburt: 2024-02-28 17:46:54.406661750 +0100
georg@vm203:~>
All my openSUSE Tumbleweed guests use ext4 (no btrfs).
My hosts use either ntfs or ext4 and only one uses btrfs.
Your system uses German locale (so does mine)
> stat /etc/fstab
Datei: /etc/fstab
Größe: 4447 Blöcke: 16 EA Block: 4096 reguläre Datei
Gerät: 0/33 Inode: 261 Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Zugriff: 2024-02-28 16:09:52.354950058 +0100
Modifiziert: 2024-02-02 16:12:11.726682603 +0100
Geändert: 2024-02-02 16:12:11.726682603 +0100
Geburt: 2024-01-22 17:21:54.759991495 +0100
>
in order to show results in English please use LANG=C like this
> LANG=C stat /etc/fstab
File: /etc/fstab
Size: 4447 Blocks: 16 IO Block: 4096 regular file
Device: 0,33 Inode: 261 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-02-28 16:09:52.354950058 +0100
Modify: 2024-02-02 16:12:11.726682603 +0100
Change: 2024-02-02 16:12:11.726682603 +0100
Birth: 2024-01-22 17:21:54.759991495 +0100
>
It also occurs in Pure Oracle Virtualbox OpenSUSE Hosts and Oracle Virtualbox OpenSUSE Guests - the date and time are not the same - they are not epoch and they are not correct - the copy has current time but the correct date and time are not there on the guests.
Considering the fact that
host: MS Windows 10 (“pure” Oracle VirtualBox 7.0.14)
guest: Kubuntu 23.10 (“pure” Oracle VirtualBox GuestAdditions 7.0.14)
works fine as well I think there is some strong evidence that openSUSE Tumbleweed might be the cause of the problem.
I suspect it is in the code that we have to patch for the 6.7.X kernel - they have made changes that VirtualBox kernel code failed to build due to API changes (More security CVE’s that get patched that step on where VirtualBox does it thing). We are looking at how Qemu is doing their file sharing to see if they do something different in their fixes. Fedora is now using Qemu code in the their VirtualBox kernel and we are going to try it - it takes a few days to test so be patient.
Remember that Tumbleweed is bleeding edge and we try to stay ahead of the kernel changes - but getting a clean compile and it working are not always right on the first couple of tries.
Remember, in computing, the difference between a bug and a feature is a feature is a bug with seniority.
It is a bit more complicated. If I generate a kernel using openSUSE’s 6.7.7 source AND their configuration, it works. If I install their kernel built by OBS from the same source and configuration, it fails. It makes no sense.
I’m not familiar with OBS (have never used it) so I cannot comment on this.
May be you should ask on the OBS mailinglist for help.
OBS (Open Build System) is how software become OpenSUSE signed for distribution (and a lot of other things like building for other hardware types and release versions - Tumbleweed, 15.5, 15.6 without having to install each version).
I’m aware of what OBS is but I have never used it myself. So I have no idea why building (from the same sources) locally renders different results to building with OBS.
Therefore I just wanted to point out that the OBS mailinglist might be a good place to ask for help.