search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
670 stars 66 forks source link

Preventing write access by multiple users at a time? #286

Open anaestheticsapp opened 3 years ago

anaestheticsapp commented 3 years ago

There is currently no way to prevent more than one user from writing to a file that is currently being worked on with the Native File System API. This causes a problem when multiple users are editing the same file on a shared network drive. If User B opens a file after user A, user B can save changes whilst user A is still working on the same document. Once user A saves the file, changes made by user B are overwritten, causing data loss.

This is not possible in Excel, for example, where changes to a file are prevented whilst open by another process.

Is there a way to work around this issue?

jimmywarting commented 3 years ago

Is there a way to work around this issue?

for now maybe try to compare the lastModifiedDate from getFile() before saving?

slaymaker1907 commented 3 years ago

I'm not sure this is a good idea since locking files is not always possible. For example, a network drive or FUSE drive might not provide the ability to lock files.

ftreesmilo commented 3 years ago

It would be nice to have an event or some way of checking that a file was edited via an external editor... rather than having to try to read the file and getting error and hoping a retry will work... like #72

mkruisselbrink commented 3 years ago

My hope is that we'll be able to expose the "locking" part of the AccessHandle proposal in #310 for arbitrary files, even if the "in-place" behavior of that API will be limited to files on the origin private file system. There is of course the problem as mentioned that actually locking files might not always be possible, but that might be better than nothing?

slaymaker1907 commented 2 years ago

For anyone looking at this, I've come up with a few ways to implement this at the application level (obviously not ideal since it doesn't prevent external applications from violating the lock guarantees):

  1. Just use the Web Locks API which works across multiple tabs/windows (but not cross browser or with private windows).
  2. Use a consensus protocol like raft to elect a leader thread of execution which manages the lock(s). Care must be taken with this option to handle non-graceful exits (i.e. what happens when you kill one browser process). This option has the advantage of working where web locks work as well as with NFS and other tabs. You could even handle something like Google Drive/OneDrive which normally mess up read/write ordering depending on implementation.