User Story #988 (closed)
Opened 16 years ago
Closed 10 years ago
File corruptions/immutability guarantees under OmeroFs
Reported by: | jamoore | Owned by: | cblackburn |
---|---|---|---|
Priority: | major | Milestone: | Unscheduled |
Component: | OmeroFs | Keywords: | scripting, security, trust |
Cc: | cxallan, fs@… | Story Points: | n.a. |
Sprint: | n.a. | Importance: | n.a. |
Total Remaining Time: | n.a. | Estimated Remaining Time: | n.a. |
Description
Another use case discussion for OmeroFs related to: #860 and #890.
sha1
The sha1 is currently computed on import (and should be by all clients). In Beta4, my plan was to have the server check all uploads against the sha1 and throw an exception if they don't match. This is important both for noticing physical corruption and tampering with scripts.
immutability
However, if files are mutable, then the sha1 isn't worth its wait in hex. Which means I was also going to suggest the romio library support some sort of UNFINISHED and IMMUTABLE flags. Not sure what that entire workflow would look like, or if it would be necessary on all files, but now with OmeroFs it's even a bit more complicated.
Ideas
One possible solution would be to allow "snapshots" of OmeroFs files. This would let users keep their files mutable, but once they left the UNFINISHED status, the server could take a snapshot if they were used in a particular way, e.g. an administrator marking them as "trusted" for scripting. The question becomes which OriginalFile entries do the clients work with: the OmeroFs one or the snapshot.
Similar to #941, this may be a case of OmeroFs configuration in which one must start the process with:
./omerofs --add /my/trusted/path --trusted --snapshots
I realize this is getting away from the original purpose of OmeroFs which was to prevent data/file duplication, but since OmeroFs functionality may become very popular, we need to make sure we can still control the data to some extent when necessary.
Change History (6)
comment:1 Changed 15 years ago by cblackburn
- Milestone changed from OMERO-Beta4 to Future
- Status changed from new to assigned
comment:2 Changed 11 years ago by mtbcarroll
- Cc fs@… added; dzmacdonald removed
comment:3 Changed 10 years ago by cblackburn
Is this addressed/made redundant by the OMERO 5 import workflow?
comment:4 Changed 10 years ago by jamoore
This is covering a couple of larger items than we've covered so far with FS. This should be migrated to trello and closed "duplicate". I'll do that during my next round of ticket cleanups.
comment:5 Changed 10 years ago by jamoore
- Status changed from assigned to new
comment:6 Changed 10 years ago by jamoore
- Resolution set to duplicate
- Status changed from new to closed
Moved to Future to clear from 4.0. Needs to be rescheduled.