Please describe the problem.
I have a repository with two directory special remotes that use the same mount point (it's a USB SD card reader using udevil). I use "git-annex-command" with lsblk and grep using the UUID to prevent git-annex from attempting to sync with the remote if it's not mounted. When trying to import from the second remote, I get "file content has changed" for every file, which seems to be related to inode-based caching.
Each of the remotes uses a subdirectory of the mount, though I did change the directory for the first one (it originally used the mount point directly).
What steps will reproduce the problem?
- Create a directory special remote on a removable device and import from it
- Create a second directory special remote on a second removable device at the same mount point and import from it
What version of git-annex are you using? On what operating system?
8.20201130-g75988a790, Debian Buster
Please provide any additional information below.
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
$ git annex import --from=pi1541 master:c64
list pi1541 ok
import pi1541 nav96.d64
file content has changed
ok
import pi1541 fb64
file content has changed
ok
import pi1541 cbmcmd22.d64
file content has changed
ok
import pi1541 cbmcmd22.d80
file content has changed
ok
...
# 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've used it successfully on Linux and Android. My attempts on Windows have been less successful, though I never tried with core.ignoreStat=true. Now I'm trying to use it to manage the SD cards for various devices: my Pi1541, Odroid Go, and Sansa Clip Zip.
Calling this done because I'm fairly sure if it was some kind of inode related bug, it would be fixed now by changes to the directory special remote. Please do followup if you still see the bug with the most recent git-annex release, or have other information about how to reproduce the alleged behavior. --Joey
git annex enableremote pi1541 <new mount point>/1541, and the problem went away. But it doesn't seem like having different mount points for removable devices should be a requirement.I don't think this has anything to do with mount points being in common. Consider that, a single disk with a git-annex repository, and 2 directory special remotes all on it has everything under a common mount point. And I'm pretty sure works. Also there's just nothing in the relevant code that cares what the mount point is.
It looks to me like the inode was somehow not the same in the "list" stage of the command as it was in the "import" stage, or the file that was seen in the first stage was no longer present in the second stage. I don't see how that could be a git-annex bug. It could, for example, happen if one SD card was mounted there at the "list" stage, and then a different card got mounted there at the "import" stage, or even if the SD card just got unmounted in between the two stages.
I have not been able to replicate the problem either, using 2 removable devices on the same mount point, 2 special remotes, etc. So you will have to show me how to reproduce this if it's actually a bug.
I don't think linux would change inode numbers while the filesystem was mounted. But each mount of FAT gets new inode numbers, since FAT doesn't actually have them and linux makes them up. So the filesystem being unmounted and remounted for some reason in between the two steps of the import would explain the behavior.
Note that I've opened ?import tree from FAT does unnecessary work due to inode instability after thinking of some other consequences of this.
Well, the changes I made for that todo make changes to inodes due to remounting in the middle of an import not cause behavior like this. Of course I don't know that's what caused this behavior, but it does seem likely those changes would turn out to have fixed this, if we understood how to reproduce the problem.