I must tell you that we have the same problem still. It is affecting both Keynote and Powerpoint, and probably a lot of other apps too. Just because these particular apps are often having changes done by multiple users at the same time.
I made an experiment. I set up SMB networking and tried to edit the same Keynote file in both computer, both the one hosting the file and the SMB client computer. Both running OSX.
Then when I tried to save the first file, it was OK, when I tried to save the second file I got a message like this:
" The document “TestConcurrentWrite” could not be saved. The file has been changed by another application. "
Due to these unexpected changes, Keynote may be unable to save your changes. Click Revert to load the changes made by the other application. Click Save Anyway to attempt to overwrite the changes made by the other application. You can also click Save As to attempt to save your changes to a different file.
I got options to Revert, Save anyway, Save as.
Makes sense. but why not when concurrently saving to Seadrive?
Is it some hidden OSX feature, since this is a network drive, OSX will understand that it can have changes from other users? How is Seadrive working, can we change the type of drive and have OSX treat it differently? Can we disable cache?
Here is an idea, what if disabling cache could help here? Could it be that OSXFUSE believes it has the latest data and does not see that another user changed the file?
I think this could be relevant maybe?
https://github-wiki-see.page/m/osxfuse/osxfuse/wiki/Mount-options
nolocalcaches
The nolocalcaches
option disables (in the kernel) the unified buffer cache (UBC), vnode name caching, attribute caching, and readaheads. This means the kernel will have to call the user-space file system upon every operation. The purported “benefit” is that the kernel would be able to “pick up” file changes that occur unbeknownst to the kernel.
For example, in the case of SSHFS, if a file was changed on the server, macFUSE has no way of knowing about it–with nolocalcaches
, macFUSE will have no cached information and will be forced to talk to the sshfs program. The SSHFS program has its own cache, which you can also disable using the cache=no
option. If all caching is thus disabled, all operations would end up going to go to the SFTP server, resulting in an apparently up-to-date view of the remote file system. There are major caveats, however. nolocalcaches
makes the operating system work in an abnormal mode, so the relevant code paths may not have been well tested. The option also creates significant overhead–file operations could end up being much slower. Besides, since SFTP provides no synchronization or locking, there are no consistency or ordering guarantees if multiple clients write to the same file concurrently. My strong suggestion is to realize that SFTP is merely a utility to access remote data, and not a means of distributed file sharing in the same vein as NFS, AFS, Coda, and so on. Of course, you are welcome to create a true distributed file system based on macFUSE.