File access and modification times cannot be set separately as it seems to be an issue with the NFS client which always modifies both. Can be reproduced with 'touch -m' and 'touch -a' commands
Workaround with latest FUSE-T is to use -o noatime and/or -o nomtime
There is also new -o nfc (added in v1.0.21) option which improves UTF8 encoding issues when working in multiplatform environment by enforcing all content saved to mount to normalise to NFC (used on Linux and Windows).
New options can be used in rclone mount command:
rclone mount remote: mountpoint -o nfc -o noatime
There are still issues with UTF8 encoding when content is saved on macOS to remote via rclone copy/move/sync (as it is NFD normalised) but this should be alleviated by VFS normalisation which is aimed for rclone v1.64:
To make rclone macOS mount to work both in Finder and shell, only way now is to make sure that your mount does not have any files using NFD normalization and use -o nfc -o modules=iconv,from_code=UTF-8,to_code=UTF-8 with fuse-t. macFUSE is totally broken.
I actually just switched back to the KEXT. I know the days are numbered but, at least for now, it was a (mediocre) solution to my problem.
I haven't had time to fully jump in and debug or gather a working minimal example but I keep running into problems that I think are more related to an idiosyncrasy in VLC than in FUSE/FUSE-T and/or rclone.
When you open a video in VLC, it opens in a mode that allows for some modification (sorry, I don't recall the flag). These are on crypt-wrapped local "remotes" stored on an external drive.
--vfs-cache-mode off: Reads the file perfectly fine. When you go to unmount, you get lots of errors in the logs but the files are untouched and they don't have an effect other than to slow down the unmount. (acceptable)
--vfs-cache-mode writes: Writes the files back which is very slow and updates the ModTime (unacceptable and slow)
--vfs-cache-mode off: VLC just can't read the file. It gets itself in a loop. (NOT usuable)
--vfs-cache-mode writes: Reads the file and doesn't write the whole thing back from the cache but does update ModTime (not ideal but fast)
So, for now, I am sticking with macFUSE and no cache. I am fairly certain that the updated ModTime is correct as far as rclone behavior goes because VLC is opening to write so it isn't related to the fixed issue in FUSE-T nor is there a bug in rclone.
And I am know my days are numbered. If the KEXT becomes too unstable or Apple blocks them for good, I will have to make due (probably decide to stop caring about ModTimes but that will make me sad. And I don't like --size-only for later backups). But given that it is working, I am going to stay in my ways.
@jwink3101 I'm curious what happens if you try the same VLC experiment with a normal local file (not mounted via rclone). Does the ModTime still get updated?
I'm interested because I also care about ModTimes and have seen some similar unexplained issues with them when mounting on macOS (and specifically upon unmounting, like you described). More recently I've been wondering if there might be an issue in the VFS layer itself, as I've also seen some odd behavior with rclone serve sftp, which shouldn't be using FUSE at all (but I'm not yet sure whether or not the issues are related).
Hmm. More stable? Probably; SMB is quite stable overall, and has been so for several years.
But the issue is "speed". SMB is "ok" I guess; but NFS is blindingly fast (for many reasons, a few of which include the little regard they have towards complex authentication features, although v4 is supposed to play well with Kerberos and such).
As a frontend to serve remote cloud storage I think speed is not really critical - your bottleneck is somewhere else anyway. Similarly all security and authentication or their lack is not so important when only used for local machine.
We are talking here about local server not client. If you try serving nfs and/or smb from macOS you will discover soon that none is rock solid stable. Clearly their dev in macOS environment is not priority.
I stand corrected! Aye, you're absolutely correct in that; in fact, I have never managed to share anything on my Mac to any of the other computers in the network — no matter what I tried (granted, I didn't try very hard).
My apologies for the confusion. Indeed, I was thinking about the client-side, not the server-side of sharing...
I was doing something with --fuse-flag but in playing with -vv mode, I saw to make it passed properly, I had to do something like --fuse-flag '-o' --fuse-flag 'backend=smb'. I should have read the other. It is a bit confuising:
--fuse-flag stringArray Flags or arguments to be passed direct to libfuse/WinFsp (repeat if required)
-o, --option stringArray Option for libfuse/WinFsp (repeat if required)
I will test it when I am at work today (I stull use the kext FUSE at home).
@kapitainsky interesting! I am curious what you think and how it compares to the nfs flavor of FUSE-T. Does it seem relatively stable? Any bugs so far? Haven't tried it myself yet, but I am interested as smb seems to be the most reliable protocol on mac these days (ironic, as it was developed for windows...)