Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should not encourage overriding write protection of files managed by large file versioning solutions like git annex or DVC #236848

Open
mlell opened this issue Dec 23, 2024 · 1 comment
Assignees

Comments

@mlell
Copy link

mlell commented Dec 23, 2024

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.

Steps to Reproduce:

  1. Download git annex (e.g. Linux standalone
  2. Use the "runshell.sh" script to launch a shell with git annex enable
  3. git init
  4. git annex init
  5. echo "Hi" > testfile
  6. 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
  7. git commit -m "Add annex'ed file"
  8. In VS Code, open "testfile" and make any change
  9. 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"
  10. 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.
Copy link

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.

Happy Coding!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants