Add long path support wrt #39

[hasufell]

No description provided.

[sergv]

Looks like this function is going to have different semantics than the base one even with this PR included.

As far as I see base's Path -> Handle counterpant for Windows is defined at https://github.com/ghc/ghc/blob/fd40eaa17c6ce8716ec2eacc95beae194a935352/libraries/ghc-internal/src/GHC/Internal/IO/Windows/Handle.hsc#L853.

There still going to be extra things that base does and this package doesn't, like some sort of file access optimization, no idea what it does though: https://github.com/ghc/ghc/blob/fd40eaa17c6ce8716ec2eacc95beae194a935352/libraries/ghc-internal/src/GHC/Internal/IO/Windows/Handle.hsc#L875.

There's also going to be handling of locked files that is not done in this package as far as I see, though I haven't checked above openFile function maybe there's something somewhere. Locking is checked after aforementioned optimizations https://github.com/ghc/ghc/blob/fd40eaa17c6ce8716ec2eacc95beae194a935352/libraries/ghc-internal/src/GHC/Internal/IO/Windows/Handle.hsc#L877.

There's also some attempt at truncation if we're overwriting file https://github.com/ghc/ghc/blob/fd40eaa17c6ce8716ec2eacc95beae194a935352/libraries/ghc-internal/src/GHC/Internal/IO/Windows/Handle.hsc#L890.

All in all this would mean that file-io is not a drop-in replacement for what base does and someone may be able to observe the difference by switching to file-io just like with long paths.

[hasufell]

All in all this would mean that file-io is not a drop-in replacement for what base does and someone may be able to observe the difference by switching to file-io just like with long paths.

Honestly, I don't feel like I want this to be a strict drop-in replacement, especially since this package uses proper Win32 functionality and there is no posix emulation layer involved. Even with the native winIO manager in GHC, there may be subtle differences.

Long path support is definitely something major, so supporting it makes sense.

For other invariants, I think we'd need to find a test that demonstrates different behavior first.

[hasufell]

Truncation is already tested here when writing over an existing file:

file-io/tests/Properties.hs

Lines 196 to 205 in e2b5ebc

	existingFile2' :: Assertion
	existingFile2' = do
	withSystemTempDirectory "test" $ \baseDir' -> do
	baseDir <- OSP.encodeFS baseDir'
	let fp = baseDir </> [osp|foo|]
	OSP.writeFile fp "test"
	r <- try @IOException $ do
	OSP.openExistingFile fp WriteMode >>= \h -> BS.hPut h "boo" >> hClose h
	OSP.readFile (baseDir </> [osp|foo|])
	Right "boo" @=? r

And it seems correct to me, as we set it to truncate here:

file-io/windows/System/File/Platform.hsc

Lines 134 to 135 in e2b5ebc

	WriteMode -> Win32.tRUNCATE_EXISTING
	AppendMode -> Win32.oPEN_EXISTING

[sergv]

It looks like a good idea for implementing furnishPath would be to reuse whatever base does via C function here https://github.com/ghc/ghc/blob/fd40eaa17c6ce8716ec2eacc95beae194a935352/libraries/ghc-internal/src/GHC/Internal/IO/Windows/Paths.hs.

Apart from matching semantics it would mean less copying around. The only drawback is that someone will need to check with each ghc release whether the foreign function is still named the same.

Otherwise all those conversions below to and from lists of characters somewhat undermine the cool idea of sticking with byte arrays.

[sergv]

I suggest to change

           ws "." `elem` WS.splitDirectories (WS.pack path) ||
           ws ".." `elem` WS.splitDirectories (WS.pack path))

to

           any (\x -> x == ws ".." || x == ws ".") WS.splitDirectories (WS.pack path))

[sergv]

Isn't there a way to leverage short byte string's isPrefixOf here?

[sergv]

Isn't there a way to leverage short byte string's isPrefixOf here and below?