Please describe the problem.
I am using a directory special remote with "exporttree=yes" and "importtree=yes" to manage my music collection on the SD card for my Tangara. Some filenames produce an "invalid argument" error when git-annex tries to export them to the card even though the filename is perfectly valid for vfat. The main commonality seems to be multiple dots in the filename, though other files with multiple dots work fine.
What steps will reproduce the problem?
- Create a repository with a bunch of files that have multiple dots in them in different places
- Create a directory special remote on a vfat filesystem with "exporttree=yes" and "importtree=yes" and no encryption
- Attempt to export or sync files to the directory special remote
What version of git-annex are you using? On what operating system?
10.20250605-gb9e3cf8780a04c8b1ac0cf4768c9ec510483477c Linux Mint
Please provide any additional information below.
$ git annex sync --content
commit
On branch main
nothing to commit, working tree clean
ok
list tangara ok
update refs/remotes/tangara/main ok
unexport tangara Music/Cloudpunk/City of Ghosts/07. Home is Now.mp3 ok
...
unexport tangara .git-annex-tmp-content-SHA256E-s7284686--102594598eea9c5e7fd96ef20e9d5fd0485244716a1b5e95a528ca887a81ae59.mp3 ok
...
export tangara Music/Cloudpunk/City of Ghosts/01 - Bandit Queens.mp3 ok
...
export tangara Music/KIRA/KIRA - The Introduction (Deluxe Edition)/KIRA - The Introduction (Deluxe Edition) - 05 Games (feat. Ruby & Gumi).ogg
/media/ciara/F0F5-1E76/Music/KIRA/KIRA - The Introduction (Deluxe Edition)/: openTempFile template KIRA - The Introduction (Deluxe Edition) - 05 Games (feat. : invalid argument (Invalid argument)
failed
export tangara Music/KIRA/KIRA ft. GUMI - Burn Me Down.ogg
/media/ciara/F0F5-1E76/Music/KIRA/: openTempFile template KIRA ft. GUMI - : invalid argument (Invalid argument)
failed
...
# End of transcript or log.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I use it quite successfully to archive media on removable spinning hard drives.
Reproduced this, and found the filename it's using with strace:
The problem is the trailing space in the filename, which VFAT does not support:
There was already a similar workaround for of not allowing a filename to end with ".", so I made it also check for whitespace.
I ran into this error during the
exportof a view to FAT32. At least some of the problems were caused by how git-annex constructed the view's filenames (or temporary transfer filenames), I believe. The filenames are constructed from path elements, which may get truncated, and so the final filenames could end up with trailing spaces. Upgrading to the current version has fixed almost all of those errors.What appears to continue to be a problem are filenames with percentage signs in them, e.g.,
)
foobar 100%.bin. As far as the filesystem is concerned,%characters themselves are obviously fine, because git-annex uses them for all view branch filenames, and the export generally works for them. (For now, I've renamed files to, e.g.,foo 100 percent.bin, and it works 100% now.Reproduced a problem with that filename:
(Without check=strict, it does not EINVAL but
lsshows that the filename created is "foobar 1.bin")But, the '%' is not responsible for the problem really:
The problem is just that FAT with check=strict doesn't allow any spaces in the filename. And I think there's just nothing git-annex can do about exporting trees with filenames with spaces to filesystems that don't support spaces in filenames.
Perhaps you are using some other mount options though that have a different behavior where '%' is really responsible for the problem. If so, I think you should file a new bug report with enough details to reproduce the problem.