Recent comments posted to this site:
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.
/tmp
, which maps to some place under /private
).
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.