Cannot write modification times...

Posts: 25 · hapEcat 12 May 2022, 21:03

"Cannot write modification times" warning has just started showing up as of today.
My question is what effect will this have on future comparisons, or will it just be these annoying warnings?

: FFS_Warning_2022-05-12 15-34-46.png (48.55 KiB) Viewed 1387 times

: CompletedWarnings_2022-05-12 15-36-53.png (49.07 KiB) Viewed 1387 times

Posts: 25 · hapEcat 24 May 2022, 02:03

Well, my "Q" has been answered.... "the old-fashioned way".
Without "Mod Dates", comparisons see the files as new files, and calls for an unnecessary Sync after every comparison. This unnecessary Sync has been going on for the past 2wks, and having to pick through 364 files (for manual comparison) has become annoying, to say the least.
I have 4 backups of a W10/Linux shared NTFS DATA partition; 3 exFAT USB sticks, and 1 exFAT SDXC card. Only the SDXC card has started being affected by the lack of "Mod Dates".

Posts: 25 · hapEcat 28 May 2022, 18:27

It appears that the lack of "Modification Time" being written, is definitely a Linux FFS issue, and not a W10 FFS issue. The "Mod Times" are written to the SD card backup media in the W10 version of FFS, but are not written to the same SD card backup media in the Linux version of FFS.

Linux ScrnSht of files that need to be written to SD card backup media that have been written to SD card media multiple times, using the Linux version of FFS.

: 1LinuxFFS_ScrnSht_2022-05-28 13-05-32.png (233.93 KiB) Viewed 1325 times

W10 ScrnSht of the same Comparison as on Linux, after those files had been written to the SD media using the W10 version of FFS

: 2W10FFS_ScrnSht_2022-05-28 05.24.04 PM.png (95.24 KiB) Viewed 1325 times

The ScrnSht file above was then attempted to Comp/Sync to the SD card backup media with the Linux version of FFS, but again there was a failure to write the "Mod Time" of the file.

: 3LinuxFFS_ScrnSht_2022-05-28 13-45-46.png (119.83 KiB) Viewed 1325 times

Posts: 7050 · Zenju 28 May 2022, 18:46

The SD card is mounted into "/media/hap/". Whoever implemented this mount point apparently didn't implement "futimens" (and maybe even returned the bogus error code EPERM?).
Or maybe it is indeed a permission issue, but I don't think so. In any case, there is (most likely) nothing FFS can do about this.

Posts: 25 · hapEcat 29 May 2022, 03:34

The SD card is mounted into "/media/hap/". Whoever implemented this mount point apparently didn't implement "futimens" (and maybe even returned the bogus error code EPERM?).Zenju, 28 May 2022, 18:46

SD cards are considered removable media, the same as USB removable media, and auto-mounts itself, when either inserted, or at boot, without any instruction to do so.
The "Whoever implemented this mount point...", was the Linux Mint OS.
Is it possible that this is a bug in one of the updates, say v11.20?... The time frame would be about right.

Posts: 7050 · Zenju 29 May 2022, 08:38

Yes, this is an issue with Linux Mint essentially. But a Linux OS is just a bundle of packages. So you would need to find the maintainer of the package responsible for mounting the SD card, and file a feature request that they should implement "futimens".

Posts: 25 · hapEcat 29 May 2022, 20:38

Yes, this is an issue with Linux Mint essentially...Zenju, 29 May 2022, 08:38

I've spent 6+hrs today searching on how to implement "futimens", but for love nor money, I can't find anyway to implement it... But I will continue to search.
Funny thing is, the "Mod Times" were written to the SD card until May 12th. So the "futimens" must have been implemented before and up until that date.
It doesn't take long to write 113GB of data to that SD card (~30min), so...
I wonder if a reformat of the SD card would make any difference?