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
I use git-annex to maintain my music library. This means that all committed files are actually read-only. When beets is allowed to write to files (move: yes or write: yes), it will fail to do the right thing because it naively thinks it can just write to files...
Setup
OS: Debian stretch
Python version: 2.7.13
beets version: 1.3.18
A rough git-annex 101 tutorial to reproduce this would be:
mkdir music
git annex import --duplicate ~/some_album # don't do this on your main collection, you may have some surprises!
git commit -m"new files"
beets import # this will fail because the files are now read-only.
Proposed solution
I am thinking of a plugin that would run git-annex-unlock on files before editing them. I assume I would need to hook into before_item_moved and write to do this. One could simply just deny writes on those files, although it's unclear to me how to deny "moving" files...
The text was updated successfully, but these errors were encountered:
Hi! You may want to take a look at #838, which discusses roughly the same idea. For example, there's a suggestion there that the new hook plugin could help you run the command automatically without writing a new plugin.
For now, you can also consider disable the import.move and import.copy options to leave files in place on the filesystem.
Problem
I use git-annex to maintain my music library. This means that all committed files are actually read-only. When beets is allowed to write to files (
move: yesorwrite: yes), it will fail to do the right thing because it naively thinks it can just write to files...Setup
A rough git-annex 101 tutorial to reproduce this would be:
Proposed solution
I am thinking of a plugin that would run git-annex-unlock on files before editing them. I assume I would need to hook into
before_item_movedandwriteto do this. One could simply just deny writes on those files, although it's unclear to me how to deny "moving" files...The text was updated successfully, but these errors were encountered: