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 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.
luciusf [Sun, 26 Jan 2025 11:19:53 +0000 (11:19 +0000)]
rename bugs/rsyncurl_without___34____58____34___creates_local_folder_as_repo.mdwn to bugs/rsyncurl_without___34____58____34___creates_local_folder_as_remote.mdwn
Joey Hess [Sat, 25 Jan 2025 15:53:47 +0000 (11:53 -0400)]
OsPath conversion
Decent win in exportDirectories, since it operates on ShortByteString
end to end now without needing conversion. That made it worth
implementing an OsPath specific code path there.
And ExportLocation already being a ShortByteString is an good example of why
it's a good thing that OsPath uses that!
projects / git-annex.git / log