search

datalad / datalad-ria

Adds functionality for RIA stores to DataLad
http://datalad.org
Other
0 stars 1 forks source link

Decide on fate of `ensure_writeable(path.parent)` #103

Open mih opened 9 months ago

mih commented 9 months ago

The ORA implementation in -core does that. I suspect that this is implemented to deal with situations where git-annex directly interacted with the annex object try (and locked down the permissions of the key directory).

There is no "change permissions" operation in UrlOperations. This implies that such an activity would need to be implemented within/for the the basic write-operations (upload and delete). ATM they have no related parameter for something like this.

christian-monch commented 9 months ago

EDIT

The assumption made below that git-annex would not touch the RIA store on the local file system is invalid. A force-parameter should be provided in UrlOperations. If this parameter evaluates to True, the operation should try to modify permissions, if necessary.

From my analysis of datalad.distributed.ora_remote I would remove ensure_writeable completely.

Rationale:

ensure_writeable is used in two of the IO-classes of ora-remote, i.e. in LocalIO and in SSHRemoteIO.

In both classes it is used in the following methods:

  • rename
  • remove
  • removed_dir

Of these methods, rename is only used in the implementation of SpecialRemote.transfer_store, remove is only used in the implementation of SpecialRemote.transfer_store and SpecialRemote.remove, and remove_dir is only used in the implementation of SpecialRemote.remove. So in summary, ensure_writeable is only used to implement operations on the remote access, i.e. in the implementation SpecialRemote.transfer_store and SpecialRemote.remove. Since we control the organization of the special remote, we can decide or enforce (via configuration requirements) that the special remote has the necessary access-permissions.

According to a comment in datalad.distributed.ora_remote, the method ensure_writeable was introduced in case that

[...] git-annex ever touched the key store [...]

I would consider this event, i.e. git-annex touching the keystore, an administration error that should be rectified by the administration. From my point of view there should be no reason for git-annex to touch a keystore other than via the git-annex special remote.