comment
This commit is contained in:
parent
bfe75f0517
commit
4ca8e95773
1 changed files with 21 additions and 0 deletions
|
@ -0,0 +1,21 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 5"""
|
||||||
|
date="2022-08-19T17:01:42Z"
|
||||||
|
content="""
|
||||||
|
@skcin I'm very sorry that happened to you. I suppose it's not data loss,
|
||||||
|
but it sounds like a mess. You should be able to examine `git log` to find
|
||||||
|
what got imported, and run `git-annex unannex` on it, and then move it back
|
||||||
|
to the right place.
|
||||||
|
|
||||||
|
Seems like I underestimated the chance this would be a foot bomb.
|
||||||
|
I now think that git-annex import and the directory special remote should
|
||||||
|
skip over symlinks. Probably with an informative message to avoid silently
|
||||||
|
doing nothing in cases where users had been using them intentionally to
|
||||||
|
follow symlinks.
|
||||||
|
|
||||||
|
Such a check will be race prone, but that is only likely to matter if an
|
||||||
|
attacker is racing it to replace a file with a symlink, and as I discussed
|
||||||
|
in previous comments, such an attacker seems like they would be able to
|
||||||
|
accomplish the same thing with the write permission they must have.
|
||||||
|
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue