Joey Hess [Wed, 5 Feb 2025 15:56:26 +0000 (11:56 -0400)]
OsPath conversion of Annex.YouTubeDl
The change of R.doesPathExist to doesFileExist I think fixes a reversion
introduced in commit 1ceece3108f03badcca0d9c64cd287f9352656b3. Before
that commit, it was doesFileExist, and I assume to point is that this is
only supposed to return files, not any subdirectories that yt-dlp might
create while running.
Joey Hess [Wed, 5 Feb 2025 15:14:45 +0000 (11:14 -0400)]
OsPath conversion of Remote.Adb
Note that the additional use of System.FilePath.Posix likely fixes a
problem if this were used on windows. The AndroidPath uses / directory
separators. Before this, on windows, \ would have been used.
The change to newtype AndroidPath is only documentation.
Joey Hess [Thu, 30 Jan 2025 20:51:42 +0000 (16:51 -0400)]
fix truncateFilePath edge case on windows
If the filepath starts with something that is not valid utf-8, it would
have returned "". And if the filepath was all non-valid utf-8, it would
also return "".
Joey Hess [Thu, 30 Jan 2025 20:31:49 +0000 (16:31 -0400)]
try fixing windows test suite
Test suite is failing in windows in conflict resolution tests, where the
automatic conflict resolution adds in a .variant file. On windows, those
files are somehow missing. I don't understand why, and the test failures
only happen on appveyor and not in a local windows VM.
So, since replaceFile was recently changed to remove a windows specific
ifdef, put it back, to see if that is somehow causing these failures.
Joey Hess [Thu, 30 Jan 2025 18:34:21 +0000 (14:34 -0400)]
bring back OsPath changes
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.
Joey Hess [Thu, 30 Jan 2025 18:23:00 +0000 (14:23 -0400)]
fix FileIO openTempFile on Windows
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.
Joey Hess [Thu, 30 Jan 2025 18:23:00 +0000 (14:23 -0400)]
fix FileIO openTempFile on Windows
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.
Joey Hess [Wed, 29 Jan 2025 22:59:09 +0000 (18:59 -0400)]
throwing away a week's work
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.
Joey Hess [Wed, 29 Jan 2025 21:22:21 +0000 (17:22 -0400)]
disable OsPath build flag on windows for now
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.
Joey Hess [Mon, 27 Jan 2025 20:55:07 +0000 (16:55 -0400)]
more OsPath conversion
keyFile has a nice improvement; since a Key is a ShortByteString, it can
be converted to an OsPath without needing the copy that was done before.
Unfortunately, fileKey has to convert from a ShortByteString to a
ByteString in order to use attoparsec, and then the results get
converted back to an OsPath, so there are now 2 copies.
Maybe attoparsec will eventually get a ShortByteString API,
see https://github.com/haskell/attoparsec/issues/225
Joey Hess [Mon, 27 Jan 2025 19:54:24 +0000 (15:54 -0400)]
optimise literalOsPath
Taking a ShortByteString and using OverloadedStrings should avoid it
being converted from a String.
The reason there is no IsString instance for OsPath is presumably the
bad behavior of IsString for ByteString on unicode btw. But
literalOsPath won't be used with unicode in git-annex.
projects / git-annex.git / log