mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment and todo

Browse source
This commit is contained in:
Joey Hess 2020-06-11 14:05:01 -04:00
parent 2062604327
commit e15ab727eb
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 48 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

30
doc/forum/Can__39__t_drop_a_file_present_in_special_remotes_only/comment_1_e03ec3be310f5c0e02457ac053e6afdd._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2020-06-11T17:36:54Z"
content="""
The reason git-annex is preventing you from dropping a file in this
situation can be understood if you imagine that you've given me and a
friend access to your remotes.
Each of the three of us runs git-annex drop --from one remote. We all
picked a different remote. So each git-annex, running at the same time,
see two copies of the file, so assume they can delete the third copy.
And so all 3 copies get deleted.
Admittedly, this is more likely to happen if there are only 2 remotes and 2
people involved, not 3 or more, and would be a big cooincidence even with
2 people. But git-annex aims to avoid losing content even in unlikely cases.
So it requires that, in order to drop the file, at least one of the other
repos have a copy, and be able to lock it in place, preventing it from
being dropped from that repo.
Unfortunately, the only remote that can lock content currently is a
git repository. (Maybe that [[could be improved|todo/lockContent_for_special_remotes]].)
The solution for you it to either use --force like the message says
(only if you're sure nobody else is dropping the files from the other remotes
at the same time), or to also have a git remote somewhere that contains
the file.
"""]]

18
doc/todo/lockContent_for_special_remotes.mdwn Normal file
View file

@ -0,0 +1,18 @@
Currently only Remote.Git implements lockContent. It seems like some other
special remotes can lock content though:
* bup and git-lfs and tahoe can't drop content, so content is implicitly locked
* S3 has an object lock feature, I don't know if it would be usable for
this, but woth investigating.
* web can't drop content, so content is also implicitly locked there
(of course web is often untrusted so git-annex won't count it as a copy
anyway then)
* appendonly remotes can't drop content. This includes S3 repos configured
with versioning. It would be worth either giving all such remotes a
lockContent that succeeds noop, or just checking for appendonly the same
places lockContent is used.
* directory could use fcntl locking
* adb could use some shell trick perhaps
* 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.