76 lines
3.4 KiB
Markdown
76 lines
3.4 KiB
Markdown
Support lockContent in more special remotes. This allows dropping
|
|
content from a special remote when the only copies are in other special
|
|
remotes, without needing to set mincopies to 0 and risk losing content.
|
|
|
|
(All the easy ones, eg read-only special remotes, are implemented already.)
|
|
|
|
* It might be possible for an external remote to lock content, but it would
|
|
be a tricky extension to the protocol, since lockContent needs to keep it
|
|
locked while running another action. There would need to be separate
|
|
actions for locking and unlocking.
|
|
|
|
If this were implemented in git-annex, and some special remote program
|
|
didn't used to support it, and implemented REMOVE w/o checking a lock,
|
|
then making that program support lockContent would run the risk
|
|
of a mixture of the old and new version being in use for the same remote,
|
|
which could result in data loss.
|
|
|
|
To avoid that, the author of the special remote would need to either
|
|
a) always do lock checking from the beginning or
|
|
b) wait long enough or document well enough to be sure that situation
|
|
never happens.
|
|
|
|
> Maybe this second part is not a problem actually? Analysis follows:
|
|
>
|
|
> There are 2 git-annex
|
|
> instances A and B, and 2 special remotes X and Y. A is using the old
|
|
> program that does not support locking, B uses the new program that does.
|
|
> Both X and Y have a copy of an object.
|
|
>
|
|
> If A is dropping from X, it will not trust Y to satisfy mincopies,
|
|
> since A cannot lockContent Y. So it will not drop from X.
|
|
>
|
|
> If B is dropping from Y, it can lockContent X, and so the drop
|
|
> succeeds.
|
|
>
|
|
> It seems it's ok for B to trust lockContent X, even though A does
|
|
> not check if X is locked when dropping from it. Because A will not
|
|
> drop from X unless it's able to satisfy mincopies by locking the
|
|
> content somewhere else. --[[Joey]]
|
|
|
|
* directory could use fcntl locking
|
|
|
|
This would need a transition, because dropping from directory first needs
|
|
to support checking for locks. Only after we're sure that any git-annex
|
|
binaries that might be in use on a machine do that is it safe for
|
|
lockContent to take the lock. So git-annex would need to be released with
|
|
the first change, then wait several months or years before making the
|
|
second change.
|
|
|
|
> Update: See analysis above, should also apply here.
|
|
|
|
Also, the directory might be on a filesystem that does not support
|
|
locking, with various failure modes. And unlike a git-annex repo,
|
|
there's nowhere in a directory special remote to record information about
|
|
locking problems with it. Getting this right seems hard..
|
|
|
|
> If lockContent throws an exception, that remote is treated the same
|
|
> as if it did not support lockContent, so if these problems can be
|
|
> differentiated from a failure to lock at all, can just throw an
|
|
> exception. But need to avoid lockContent succeeding in any case
|
|
> where removeKey will not be prevented from removing the content.
|
|
|
|
* S3 has an object lock feature, I don't know if it would be usable for
|
|
this.
|
|
|
|
It would need a transition, with dropKey first failing when the object
|
|
lock was in place, and then once that git-annex was in use everywhere,
|
|
lockContent setting the object lock.
|
|
|
|
> Update: See analysis above, should also apply here.
|
|
|
|
(S3 with versioning=yes already supports lockContent.)
|
|
|
|
* adb could use some shell trick perhaps.. But it would depend on doing
|
|
locking in /sdcard, which seems likely to be a massive ball of POSIX
|
|
incompliance and pain.
|