62 lines
2.9 KiB
Markdown
62 lines
2.9 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.
|
|
|
|
(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 misture 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.
|
|
|
|
* 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.
|
|
|
|
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..
|
|
|
|
* 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.
|
|
|
|
(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.
|
|
|
|
----
|
|
|
|
I was thinking about something related to this recently. Dropping currently
|
|
guaranteeds numcopies will be maintained for remotes that support
|
|
lockContent. But when some of the copies are on special remotes, this
|
|
is not guaranteed. It only makes sure lockContent is keeping one copy
|
|
locked, and can verify the existence of the other copies less stringently.
|
|
|
|
So perhaps it would be good to make this explicit in the configuration,
|
|
by adding a requirednumcopies. (Analagous to required content configs.)
|
|
Defaulting to 1 as now, but if the user wants to they can set it higher,
|
|
perhaps as high as their numcopies (or even just set it to 1000 and make
|
|
it be treated the same value as numcopies when it's >= numcopies.)
|