[FUSE] Undelete collections by moving them out of the TrashDirectory
Basic idea: When FUSE is mounted
--read-write, a user can undelete a collection by moving the collection directory from anywhere under the TrashDirectory to a ProjectDirectory outside the TrashDirectory.
rename methods see this operation and update the collection to set its
expires_at attribute to null, and update the
name if appropriate.
#9590 says that the TrashDirectory and everything under it should be read-only. This story adds some nuance to that rule: only collection directories under the TrashDirectory, and their contents, should be read-only. The TrashDirectory itself and all ProjectDirectories under it should be read-write, to indicate to the user that they can do (some) write operations on the contents, like this move.
Moving the collection directory anywhere else (like somewhere else under TrashDirectory, or to the mount root when it's not a ProjectDirectory) is still an error.
If updating the API record fails, that should be reflected as an I/O error from the rename operation.
#1 Updated by Brett Smith over 3 years ago
I wanted to write it down for discussion, but this is the UI proposal I feel least sure of. Requiring the user to move directories is not ideal: if all they want to do at the API level is "set
expires_at to null," they have to re-find the owning project elsewhere in the mount, and move the collection there.
Other ideas have their own problems, though. For example, allowing undelete by touching or writing to a special file is harder to discover, and doesn't follow filesystem idioms as well. And if the user does it while they're inside the collection directory under TrashDirectory, suddenly their working directory is gone. That's not a fatal problem, but it seems unfortunate.