I made some experiments to define the behaviour, the problem is, that 3 computers with installed ubuntu 20.04.1 LTS behave(d) differently (installing fuse-exfat 1.3.0 stopped the described behaviour in two of the computers, seems, that nautilus is able to bypass fuse-exfat in some conditions).
I made the tests in an alternative terminal session without active GUI and manually mounting without the fstab-entries. I repeatedly mounted the device, created files, read them with cat, modified them with touch. I did not apply status changes. Then I unmounted, mounted read-only, checked changes and changeability, seeing, that mount with -r option really protected the file system from being changed. touch xy creates a file, the time applied to the system was correct in atime, ctime, mtime but highly fractioned below milliseconds, which is not really in accordance to the exfat system where the time resolution is 2 seconds and in an additional field 10 ms. if unmounted and mounted read only again the newly created files were advanced 1 month and the seconds were rounded to the next lower even number (conforming to the time resolution of 2 seconds in the mtime and ctime, the atime was set to Dec, 31, 1979, 1:00 (+001). cat and touch (which results in the expected error message) made no changes to the files, also if unmounted and remounted rw. The same results came with remounting read/writeable. After using cat the mtime and ctime remains unchanged (1 month advanced), atime is set to the correct timestamp. After using touch all three timestamps are updated to the actual time and date (without fraction, just even seconds!) if unmounted and mounted again files that were only read, showed a further advance of the date by one month in mtime and ctime and again Dec, 31,1979 in atime. The touched files advanced by 1 month in mtime and ctime and also showed Dec, 31, 1979 in atime. Files that were only listed showed no change (remained the one month advanced as happend by the unmounting after their creation). It seems that the procedure that writes some buffers back to the hard drive during unmounting has bugs in converting to the exfat file entries. The month in the c time-structure is 0-11, in exfat 1-12, this may be an issue. The field for last access seems to be left empty. And the fractions below the 2 seconds seem to be omitted in the procedures that work with the filesystem even before flushing the buffers, but they seem to be used in the procedure, that creates a file newly. After installing fuse-exfat this behaviour stopped in one computer, in the other not (where I will try uninstall and reinstall...). A bit less important, but now with cat even the atime stays unchanged completely (other than with ext4); ctime is changed together with mtime. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1872504 Title: date modified is wrong for files on an exfat formatted drive Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: When using exfat formatted drives (e.g. my camera card) with focal fossa any access causes the date modified to be set, even when it would not normally be set, and it is set a month into the future. Installing exfat-fuse and exfat-utils results in the correct behaviour. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: ubuntu-release-upgrader-core 1:20.04.18 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Uname: Linux 5.4.0-21-generic x86_64 ApportVersion: 2.20.11-0ubuntu26 Architecture: amd64 CasperMD5CheckResult: skip CrashDB: ubuntu CurrentDesktop: ubuntu:GNOME Date: Mon Apr 13 17:27:30 2020 InstallationDate: Installed on 2020-04-12 (1 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200409) PackageArchitecture: all ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: ubuntu-release-upgrader Symptom: dist-upgrade UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1872504/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
