You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue occur when all extensions are disabled?: Yes
VS Code Version: 1.96.1
OS Version: Linux 6.12.4-arch1-1 / Arch Linux / GNOME Shell /
git annex is a tool that allows handling of large files and management of a decentralized set of repositories, allowing a sort of partial checkout (repositories can choose which files they provide) and it keeps track of which files are available in which repository. Based on that information, git annex can inform the user how many copies of each file are available at other locations. The decentral nature and handling of large files allowed the adaption for scientific computing workflows.
git annex tries to avoid storing files twice as annex'ed files can be quite big. Therefore when files are added to git annex, they are moved to a write-protected content-adressed storage living in .git/annex/objects and the original file location is replaced by a symlink to the object store. Files in this state are referred to as "locked", as they must not be edited to not corrupt the content-addressed storage.
To edit a file, first a copy must be made from the object storage to the original location. However, VSCode encourages the user to instead remove the write protection bit, which makes the object-storage writable and modifies the file inside of the storage instead of editing a copy. I know that the tool DVC, which is used to version-control machine learning pipelines has a similar system, so this problem probably applies there, too.
Potential solution: Do not offer the "Overwrite" function if a file looks like a git-annex'ed file, that is, if it (a) is a symlink (b) points to a target that follows the regex (\.\./)*\.git/annex/objects. I see that VSCode cannot support functions of random 3rd party apps so it probably does not need to offer unlocking instead of overwriting, but just not showing the "Overwrite" button would maybe be an addition that is reasonably small for a large benefit of not promoting an action that can destroy previous versions of a file that the user wants to keep.
Use the "runshell.sh" script to launch a shell with git annex enable
git init
git annex init
echo "Hi" > testfile
git annex add testfile -> The file is moved to .git/annex/objects/[shard1]/[shard2]/[hash]/[hash] and testfile is replaced with a symlink to that location
git commit -m "Add annex'ed file"
In VS Code, open "testfile" and make any change
Try to save --> A message appears "Failed to save 'core_paths.json': File is read-only. Select 'Overwrite' to attempt to make it writeable.", with a blue button "Overwrite"
Expected behaviour: VSCode warns that this looks like a git annex'ed file and should be unlocked first, or it replaces the symlink by a copy of the content. symlink. Actual behaviour: VSCode offers the blue "Overwrite" button, encouraging the user to modify the symlink target within git annex's object storage, thereby corrupting it and leading to loss of the old file content.
The text was updated successfully, but these errors were encountered:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.96.2. Please try upgrading to the latest version and checking whether this issue remains.
Does this issue occur when all extensions are disabled?: Yes
git annex is a tool that allows handling of large files and management of a decentralized set of repositories, allowing a sort of partial checkout (repositories can choose which files they provide) and it keeps track of which files are available in which repository. Based on that information, git annex can inform the user how many copies of each file are available at other locations. The decentral nature and handling of large files allowed the adaption for scientific computing workflows.
git annex tries to avoid storing files twice as annex'ed files can be quite big. Therefore when files are added to git annex, they are moved to a write-protected content-adressed storage living in
.git/annex/objects
and the original file location is replaced by a symlink to the object store. Files in this state are referred to as "locked", as they must not be edited to not corrupt the content-addressed storage.To edit a file, first a copy must be made from the object storage to the original location. However, VSCode encourages the user to instead remove the write protection bit, which makes the object-storage writable and modifies the file inside of the storage instead of editing a copy. I know that the tool DVC, which is used to version-control machine learning pipelines has a similar system, so this problem probably applies there, too.
Potential solution: Do not offer the "Overwrite" function if a file looks like a git-annex'ed file, that is, if it (a) is a symlink (b) points to a target that follows the regex
(\.\./)*\.git/annex/objects
. I see that VSCode cannot support functions of random 3rd party apps so it probably does not need to offer unlocking instead of overwriting, but just not showing the "Overwrite" button would maybe be an addition that is reasonably small for a large benefit of not promoting an action that can destroy previous versions of a file that the user wants to keep.Steps to Reproduce:
git init
git annex init
echo "Hi" > testfile
git annex add testfile
-> The file is moved to.git/annex/objects/[shard1]/[shard2]/[hash]/[hash]
andtestfile
is replaced with a symlink to that locationgit commit -m "Add annex'ed file"
The text was updated successfully, but these errors were encountered: