Please describe the problem.
Copying and renaming a file "breaks" the original. I'm not using git-annex long enough to use the correct terminology here. "Broken" means "git annex status" reports "fatal: Not a valid object name".
What steps will reproduce the problem?
Using the Assistant on Windows, create a fresh repository. Place a file called starship.jpg in the root. Make two directories, called "pic" and "space". Using Explorer, move the picture into "space". Move "space" into "pic". Go into "pic>space". Copy the image and paste it to the root of the repo. Rename the image "wallpaper.jpg".
$ git annex info wallpaper.jpg
file: wallpaper.jpg
size: 225.75 kilobytes
key: SHA256E-s225747--e5cba8967f4bea1a971e7405169056852beb3efbbf7fa2d3758c61ba769296c1.jpg
present: true
$ git annex info pic/space/starship.jpg
fatal: Not a valid object name pic/space/starship.jpg
info pic/space/starship.jpg (not a directory or an annexed file or a treeish or a remote or a uuid) failed
$ git annex status
D .\space/starship.jpg
? .\pic/space/starship.jpg
What version of git-annex are you using? On what operating system?
$ git annex version
git-annex version: 10.20220526-gc6b112108
build flags: Assistant Webapp Pairing TorrentParser MagicMime Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: mingw32 x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
local repository version: 8
OS: Windows 10 Pro, 21H1, 19043.1766
Please provide any additional information below.
There's no .git/annex/daemon.log in my repo. Probably because after encountering this issue and reproducing it for this report, I made a new repo, and it seems that the Assistant's logs ended up in the original repo's logs.
Test image used in this bug report: https://wallpapercave.com/wp/wp8215486.jpg
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'm really loving git-annex. I've been reading up and I'm more than halfway through the devlog and I'm hoping to use git-annex for a lot and a long while. Mostly, I'm expecting to use it on Linux systems, but I'd love to be able to rely on it on my (Windows) work laptop as well. Thanks for looking at my report!
Well, this appears to be a case where the assistant somehow misses the rename of the file, so it has not gotten around to annexing it.
You can get the same error message when not using the assistant, eg:
I guess that
git-annex addwould resolve your problem. The assistant should also notice the file the next time it starts up, and add it the same as it would any new file.Hi Joey, thanks for looking into this and your work on git-annex! You're correct on both counts. After posting the report I tried manually adding the file and, indeed, restarting the assistant also makes it notice the file. I'm still exploring, but what seemed to be inscrutable behaviour at first, now seems reasonable enough.
I've also encountered some access violations and I'm running into sqlite errors on WSL (1 & 2), both of which probably aren't worth reporting at this time, and the latter of which is probably out of scope of this bug tracker, anyway.