Original Date/Time is changed when Copy / View

[TTT7275]

Thanks for create this great module,

I have a problem with Original Date/Time is changed when Copy / Viewing. I created an issue in Cryptomator also ->
cryptomator/cryptomator#2700

Here is what I got :

When Copy

• Cryptomator - Some file do change the date/time some file do not. I still can't find the pattern since both files have the same pattern except it has different date time value in the file.
• rclone - All the files keep the original date/time

When Preview in Finder according to julesallen

• Both rclone and Cryptomator do change date/time to current date time.

[macos-fuse-t]

Unfortunately this is a bug of macOS that causes Preview to change file modification time (mtime) on an NFS volume

[TTT7275]

Then, we can only wait and hope they will fix it.

Thank you for your quick reply.

[julesallen]

Hey Alex @macos-fuse-t , thank you for all the work you've put in on getting the project this far. kexts are a pia!

Unfortunately this is a bug of macOS that causes Preview to change file modification time (mtime) on an NFS volume

I'm not a filesystem developer and don't know where to dig to help get this fixed. You say it's a bug in macOS, is the core OS using an old or buggy version of NFS? Has this been reported to Apple and is the core of the NFS open source?

Looks like we're not alone here! https://apple.stackexchange.com/questions/452957/mac-quick-preview-change-file-datetime-in-nfs-shares

Happy to do some grunt work to help get this solved if you need the help.

[macos-fuse-t]

I will report this bug although I'm pretty sure it was already reported in the past
Perhaps this is the culprit: nfs_vattr_set_bitmap() func:
https://opensource.apple.com/source/xnu/xnu-7195.60.75/bsd/nfs/nfs4_subs.c.auto.html

[macos-fuse-t]

A workaround is available in 1.0.22

[kapitainsky]

It is great news that nomtime and noatime has been added!

For completeness could you also add nodiratime at some stage? It would solve the same problem for directories.

[macos-fuse-t]

nomtime and noatime apply both to files and folders

[kapitainsky]

I have just tested and it does not seem to be the case - here is some folder and file on FUSE-T share:

I copy it to other location on share drive (before mtime of file would also change - but this is now working)

I copy it to local disk:

[macos-fuse-t]

How did you test?

[kapitainsky]

Also some reference to other project findings when dealing with NFS on macOS

https://github.com/me-io/docker-machine-mac-nfs-mount/blob/master/README.md

[kapitainsky]

How did you test?

fuse-t with -o noatime and then I simply use finder copy/paste. This option made file mtime not to change anymore - which is great.

[macos-fuse-t]

You should use with -o nomtime. noatime is for access time

[macos-fuse-t]

Try with a libfuse sample fusexmp_fh which would mirror your hard disk.

[kapitainsky]

You should use with -o nomtime. noatime is for access time

Yes - but this is exactly what I want - to have mtime and prevent its changes by software like Finder trying to change atime.

Actually I think this is the most common case - people usually do not care about atime and want mtime to be accurate.

[macos-fuse-t]

Correct, that's why you should mount with "-o nomtime". It won't change modify time when hitting Preview. Access time would still get updated.

[kapitainsky]

Yes it wont change - ever:) I want to know when I edited my file... But yes I do understand that people might have different requirement so great we have both options available.

With -o noatime Finder and Preview are behaving like they should - not changing mtime - I guess because they can not modify atime no damage to mtime is done.

[macos-fuse-t]

Use experimental "-o backend=smb" which doesn't have this issue. I don't know what Mountain Duck is or how it works.
See here https://github.com/macos-fuse-t/fuse-t/releases/tag/1.0.35