I uninstalled udevil in favor of udiskie, which uses a mount point name based on the label instead of the device, updated the directory to point at the new mount point with 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.

Is the relative path actually valid?

As far as I can tell, it is.

(venv3.8.6) worker-629-003:datalad_temp_test_basic_scenariocm66i4fm appveyor$ ls -id ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex
12889649026 ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex
12889649026 /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex

I cannot come up with an explanation, for the consistent behavior of ls, but not mkdir for a relative path vs. an absolute path.

(venv3.8.6) worker-629-003:datalad_temp_test_basic_scenariocm66i4fm appveyor$ mkdir ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex/testdummy
mkdir: ../../../../../../../var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex: No such file or directory

(venv3.8.6) worker-629-003:datalad_temp_test_basic_scenariocm66i4fm appveyor$ mkdir /var/folders/5s/g225f6nd6jl4g8tshbh1ltk40000gn/T/datalad_temp_tree_test_basic_scenariodi3ady04/.git/annex/testdummy
-> exit 0

A faster way of doing uninit is the following:

cp --no-clobber --dereference --recursive --preserve=all --reflink=auto --verbose ./git_annex_repo/your_symlinks/ ./target_dir/

This will simply copy (thin COW copy) symlinks (dereferenced) as normal files preserving the mtime, etc. the resulting ./target_dir/ will have your files if they existed in this annex or broken symlinks if the files were not here.

It seems that Utility.LockFile.Windows.openLock must be returning Nothing for this message to be displayed.

Which it does when CreateFile returns INVALID_HANDLE_VALUE. Which it makes sense it would do for a filename that's too long. Except that's taken to mean the locking failed due to it being locked.

(So it seems createfile with the too-long filename is creating the file but then failing that way. Which is weird.)

It might be possible to use windows's GetLastError to find out that it failed due to length, but the API docs don't seem to say what the error value is in that case.

Normally ghc modifies filenames on windows to not use the compatability layer that has this filename length limit. But since this is using the low-level CreateFile, that does not happen here.

The code that does that is not exposed (create_device_name in base's cbits/fs.c) It's basically a matter of prepending \\?\ to the path, but it also has to be made absolute and cannot contain '/'.

I've implemented something similar in git-annex, which I hope will solve this. I have not tried it on windows yet so leaving the bug open for confirmation.

This is a pure test, and the filesystem does not affect it in any way.

The test is slightly broken, in that when two paths are the same except slightly differently normalized (eg, "A" vs "A/"), it fails. Really not a great test overall, rewriting.

Also it seems common for directories under /var/folders/xx/yyyyy/ to be mode 700, so it could somehow involve permissions.

Is the relative path actually valid? There may be some case involving symlinks in the parent directories where the relative path could be wrong. This part seems to suggest there are symlinks involved:

some of these folders actually live in /private/var, despite being accessible via /var

Of course, it's a bit surprising that a relative path is used when the path is into an entirely different top-level directory. But without understanding the problem I don't know if switching to using an absolute path in that case would only happen to fix this case of the problem and not the general case, whatever that is.

# Regenerate the git annex metadata
git annex fsck --fast

Exactly what does this command do? What metadata is regenerated and what does "regenerated" in this context mean?

The script only makes one commit of the metadata when I run it on linux. (Including in an adjusted unlocked branch like windows uses.)

Since you're using git -c, git uses an env var to propagate that setting on to child processes. So it's possible something on windows prevents that working.

The issue goes away, when I place the directory in which repositories are created into the user's HOME directory (instead of /tmp, which maps to some place under /private).