Could you explain the copy-on-write integrity problem? about lfs-folderstore HOT 2 CLOSED

Sorry this is so late, I didn't realise I didn't have notifications turned on for this repo.

The main reason for not using hard links is that the data model of LFS assumes that files are immutable. They are named based on the hash of their contents, so at no time after naming the file can the content change, otherwise it breaks that assumption. That rules out sharing storage via hard links between the working copy and the repo storage, which is the most common case of duplication.

Now, potentially you could use hard links just for the repo side, so between the content of the .git/lfs folder and Dropbox in this case. You'd still have duplicates in the working copy but only one copy between the repo commits and Dropbox. I haven't explored this but it might make sense as an opt-in (there are limitations on hard links that can mean you can't always use them, e.g. across logical drives).

Although I used lfs-folderstore myself for a number of years, I've since moved to Gitea for our projects so I'm not working on it anymore so I won't be adding this myself, but in principle it's something you could add if you wanted.

from lfs-folderstore.

No worries and thanks for the clarification! Definitely understand the need to copy instead of link for checking out a working copy. I'll keep it in mind if I do make a change. For now, I have been ok by simply reducing the number of large files and using git lfs prune aggressively to reduce duplicated space on disk: I'll probably continue like that until things become an issue.

from lfs-folderstore.