Adam Heath wrote: > Currently, git-annex unlock will copy the raw bytes from its internal > store, so that the file could be modified. However, some editing > workflows don't actually modify the file, and just write out the new > contents. > > Consider the case of a workflow that writes the new version of the > file to a tmp location, then does an atomic move to the old name. > Since git-annex unlock copies the file, this means that the full file > ends up being copied twice. Also, if the new version of the file is > just a truncated version(consider a file going from 200Mbytes to 5 > bytes), then the unlock copy is a waste of disk io. > > My suggestion in this case is to hard-link. > > The workflow I am thinking of modifying(wiki-like web frontend, with > support for uploading of videos), already has a pre-commit hook, which > would use git-annex unlock first, and a post-commit hook that then > would commit the changes back.
I could make git annex unlock --readonly do it, but it seems pretty confusing. Actions that deleted the unlocked file and then put a new one in its place would succeed, while actions that rewrote it (eg, cat > file) would fail with permission denined. That's why git-annex unlock uses cp --reflink=auto. On a filesystem supporting CoW, like BTRFS, this keeps unlock very inexpensive while still providing an editable copy of the file. -- see shy jo
signature.asc
Description: Digital signature
