With old:
Cache entry not found: C:\projects\git-annex\Users\appveyor\.stack
I think fixing this will result in caching preventing a full rebuild of
git-annex each time.
I hope that the windows test suite failure on appveyor was fixed by
updating to a newer windows there. I have not been able to reproduce
that failure in a windows 11 VM run locally.
When an UNC-style path is passed into openTempFile, the returned file
starts with that same style of path. Which can cause problems, eg piping
that filename to git failed. So, convert the output filename to be
relative to the input temp directory.
When an UNC-style path is passed into openTempFile, the returned file
starts with that same style of path. Which can cause problems, eg piping
that filename to git failed. So, convert the output filename to be
relative to the input temp directory.
This was an attempt at continuing the RawFilePath transition into an
OsPath transition. Unforunately, it had multiple test suite failures on
windows. Debugging those seems that it would be more work than the
minor optimisation value of this.
Test suite failure looks like this:
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
fatal: could not open '\\?\C:\Users\appveyor\AppData\Local\Temp\1\hash-cc81b41d-dfda-4ae8-904b-b531742443cc' for reading: No such file or directory
git-annex: fd:4: Data.ByteString.hGetLine: end of file
git-annex: user error (git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--no-filters","--stdin-paths"] exited 128)
This is apparently in Git.HashObject, and probably in hashBlob, which uses a
temp file with a name starting with "hash", but I have not been able to tell
what's wrong.
I don't understand where the "\\?" path prefix (windows UNC-style path)
is coming from in the path that gets fed into git hash-file, or why git
hash-file can't open the file.
After recent changes to use OsPath, test suite fails on windows with:
Exception: Uneven number of bytes: 5. This is not a Word16 bytestream.
Hopefully this fixes it. The innefficiency of the conversion is
unfortunate.
