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

thoughts

Browse source
This commit is contained in:
Joey Hess 2022-05-10 13:25:38 -04:00
parent 3b83224e57
commit 997e96ef5e
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 35 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_3_4375a63a864306c39323fa4b159425d6._comment
View file

@ -10,7 +10,9 @@ annex.crippledfilesystem=true. Then it does use the bare form of object
filenames, which is kind of ok since it's not going to be using symlinks in
that repository.
Also, before 2016, git-annex used those names whenever annex.crippledfilesystem=true,
Also, before 2016
([[commit 2d00523609def535588b693a00d4092768e1c3c6]]),
git-annex used those names whenever annex.crippledfilesystem=true,
no matter what core.symlinks was set to. So if the files are that old..
This does seem to point to there needing to be a way to migrate the object

15
doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_4_a0d4ffdf3edadb5381f242f65fa38932._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2022-05-10T16:37:21Z"
content="""
The rationalle for using the bare object layout when on a crippled
filesystem was given in [[!commit f1b0a4b404ed835f1c4a27a92352180be8564f8a]].
Basically it may be more portable. Not a strong rationalle at all, as the
later change to not do it when symlinks are supported shows. But
I don't think worth changing at this point.
So teaching fsck to move object files to the preferred location seems the
best way. It will also deal with the situation where a bare repository gets
converted by the user into a non-bare repo.
"""]]

17
doc/todo/command_to___34__migrate__34___from_adjusted_mode/comment_5_55b5beaeba0de7bb1efcc2626570d3b5._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2022-05-10T16:56:47Z"
content="""
As well as moving the object file, fsck will need to move any other associated
files. It may as well move the whole object directory.
Locking is a concern for implementing this in fsck. There
would be a race where another process that is locking the object file
sees the object file in the old location, so tries to lock it in the old
location, but by then the object file has been moved. Seems this could
result in it making a separate lock file in the old object directory (v9+),
or might even create the object file when trying to lock it (pre v9).
Only making fsck do the move in v9+ solves half of that.
"""]]