Please describe the problem.
Except for git annex info
many (all?) other git-annex file-based commands seem to have a problem with paths behind relative symlinks to directories in the repository. Using the 'full' tracked-by-git or absolute path works. I guess git-annex relies on git for determining if a file is tracked and git itself fails to 'see' files behind relative symlinks to dirs in the repo as well.
What steps will reproduce the problem?
Run this script:
#!/bin/sh
export LC_ALL=C
chmod +w -R git-annex-link
rm -rf git-annex-link
mkdir git-annex-link
cd git-annex-link
(
git init
git config commit.gpgsign false
git annex init
# make folder structure with some files
mkdir -p level1/level2
for f in level1/file level1/level2/file;do echo "$f" > "$f";done
ln -rsf level1 link-to-level1
ln -rsf level1/level2 link-to-level2
git annex add --force-large
git commit -m "Add files"
) >/dev/null 2>/dev/null
echo;(set -x;tree);echo;echo
echo "Test results:"
for cmd in info metadata get lookupkey whereis list fix;do
for file in level1/file level1/level2/file link-to-level1/file link-to-level2/file;do
printf "git annex %10s %20s %s\n" $cmd $file "$(git annex $cmd $file 2>/dev/null >/dev/null && echo -n ok || echo -n fail)"
done
done
echo;echo "The error is: "
(set -x;git annex get link-to-level1/file)
Output:
+ tree
.
|-- level1
| |-- file -> ../.git/annex/objects/P7/z4/SHA256E-s12--17313e162321955543c4644ea8e1accc8d3039a9e0a9224429f26bafafe0d1b6/SHA256E-s12--17313e162321955543c4644ea8e1accc8d3039a9e0a9224429f26bafafe0d1b6
| `-- level2
| `-- file -> ../../.git/annex/objects/24/K3/SHA256E-s19--633195e34fd1e133557ece8767e268a0ebd9e4caedad4776bab4470c60a84439/SHA256E-s19--633195e34fd1e133557ece8767e268a0ebd9e4caedad4776bab4470c60a84439
|-- link-to-level1 -> level1
`-- link-to-level2 -> level1/level2
4 directories, 2 files
Test results:
git annex info level1/file ok
git annex info level1/level2/file ok
git annex info link-to-level1/file ok
git annex info link-to-level2/file ok
git annex metadata level1/file ok
git annex metadata level1/level2/file ok
git annex metadata link-to-level1/file fail
git annex metadata link-to-level2/file fail
git annex get level1/file ok
git annex get level1/level2/file ok
git annex get link-to-level1/file fail
git annex get link-to-level2/file fail
git annex lookupkey level1/file ok
git annex lookupkey level1/level2/file ok
git annex lookupkey link-to-level1/file fail
git annex lookupkey link-to-level2/file fail
git annex whereis level1/file ok
git annex whereis level1/level2/file ok
git annex whereis link-to-level1/file fail
git annex whereis link-to-level2/file fail
git annex list level1/file ok
git annex list level1/level2/file ok
git annex list link-to-level1/file fail
git annex list link-to-level2/file fail
git annex fix level1/file ok
git annex fix level1/level2/file ok
git annex fix link-to-level1/file fail
git annex fix link-to-level2/file fail
The error is:
+ git annex get link-to-level1/file
error: pathspec 'link-to-level1/file' did not match any file(s) known to git
Did you forget to 'git add'?
get: 1 failed
What version of git-annex are you using? On what operating system?
❯ inxi
CPU: 8-core AMD Ryzen 7 5800H with Radeon Graphics (-MT MCP-)
speed/min/max: 1450/1200/4462 MHz Kernel: 6.1.1-1-MANJARO x86_64 Up: 4h 23m
Mem: 4370.6/13832.0 MiB (31.6%) Storage: 953.87 GiB (40.9% used) Procs: 376
Shell: fish inxi: 3.3.24
❯ git annex version
git-annex version: 10.20221212-gab11fd70e
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
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: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
Please provide any additional information below.
I came across this while developing my thunar-plugins
Python package for git-annex integration in XFCE's Thunar file manager. It is easily worked around there by resolving all links before handing them to git-annex. However having git-annex handle this situation natively would be nice, e.g. by also first resolving paths it gets handed.
One motivation for such relative symlinks to directories somewhere in the repository is to make shortcuts to some deeply nested folders.
Links to files (not directories) get converted to links to the annex, so not a problem there.
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)
Yes, git-annex
is absolutely awesome, 🎉 'finding' it was one of my highlights of 2022 😉!
git-annex actually has very similar behavior to git. Consider from your example:
Compare to:
If anything, it seems that the bug is in
git-annex info
for behaving differently in this case when run on a file behind a symlink.Also this is not a problem if you
cd
to the symlink and then run commands operating on relative files.