search

cs3org / cs3apis

:arrows_clockwise: Connect Storage and Application Providers
https://buf.build/cs3org-buf/cs3apis
Apache License 2.0
53 stars 29 forks source link

Further clarified scope of lock_id #227

Closed glpatcern closed 7 months ago

glpatcern commented 8 months ago

Follow up from #226: the lock_id payload of storage requests that do not alter the content of a file MAY or MAY NOT be honored, because the storage MAY allow for modifying files' metadata (in particular grants or other arbitrary metadata) without enforcing eventual locks.

As such, the spec changed from MUST to SHOULD, with an additional MAY clause.

This only affects the comments, the protobuf payloads did not change.

glpatcern commented 8 months ago

@butonic this was motivated by the fact that EOS allows to alter xattrs no matter the lock state, and I think it makes sense: e.g. I can (further) share a file even if it's being edited by someone. How did you implement the decomposedfs in Reva edge?