Recent comments posted to this site:

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.
Comment by seanl Sun Jan 17 07:24:38 2021

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
Comment by mih Fri Jan 15 08:32:58 2021

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.

Comment by eric.w Thu Jan 14 22:15:12 2021

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.

Comment by joey Wed Jan 13 17:25:08 2021

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.

Comment by joey Wed Jan 13 17:01:07 2021

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

Comment by joey Wed Jan 13 16:57:10 2021

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.

Comment by joey Wed Jan 13 16:32:06 2021
# 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?

Comment by eric.w Mon Jan 11 22:48:27 2021

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.

Comment by joey Mon Jan 11 18:47:54 2021
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).
Comment by michael.hanke Sun Jan 10 16:10:42 2021