-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gather code and design reviews #10
Comments
Ccing @Mistuke Thanks for putting the time into pushing this forward, @hasufell! Some initial thoughts:
|
I had given this some thought, the options were as follows:
So my argument is:
I have no strong opinion, what's your verdict?
True. However, most (not all) functions are ported from
What name do you suggest?
Yes and I believe it does. The Also see https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew: "The name of the file or device to be created or opened. You may use either forward slashes (/) or backslashes (\) in this name."
I'm not too familiar with those? Why are they relevant for filenames? Does the |
Fair.
I think it should be treated as a qualified import.
Fair, but I think we should take this opportunity to clarify the semantics (or at least clearly document that the function will merely make a fuzzy "best-effort" attempt at fixing up the path.
Ahh, good catch.
See https://docs.microsoft.com/en-us/windows/win32/fileio/file-streams. In short, files in Windows are in fact more like directories, containing multiple named "streams" of content (vaguely reminiscent of extended attributes in the POSIX world). The "default" stream is named |
This is only true when using the APIs in "legacy" mode. In "legacy" mode the Win32 API calls will translate paths from their legacy form e.g. This results in accesses being faster, but also in an application not being restricted to legacy issues (e.g. Haskell programs use these filepaths internally, but at the moment we constantly have to translate between the "legacy" ones and the ones we use internally. I would expect a new API to hopefully remove this requirement. Note that Windows has a number of these namespaces A modern version of GHC will accept these and do the right thing, but [0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
They're represented by using
which is invalid. |
Yes, filepath largely ignores it, but does corrupt things when they're used. e.g The blame for this feature though lies with Mac. Data streams were added to NTFS to support interop with Macs. Macs also support this concept in HFS. The neutral term for this is called |
I don't like the design where depending on the build target the API changes. I'd need modules for Windows and POSIX paths (like In perfect world e.g. tarball/zipfile internal paths could be fitted into the same story, etc. though POSIX paths are close enough, maybe? |
There is. Half of the library is dealing with exactly this concern: |
Well, I don't have a clear picture what needs to change. So I'd rely on pull requests. The filepath ported functions are all in https://github.com/hasufell/abstract-filepath/blob/master/lib/AFP/AbstractFilePath/Internal/Common.hs |
But the reality is that this doesn't match the real world. At some point you have to have platform abstractions. Not doing so is how Windows builds ended up being so much slower than the rest. Assuming a POSIX view of the world has caused so much trouble on non-POSIX systems that really I wish we wouldn't. The world is just not POSIX. To me doing this honestly provides no extra benefits at all over using paths as strings. I have to heavily process them anyway for any use, so I might as well use a representation that's easily read from C then. |
@hasufell I don't believe anything has to necessarily change from the API point of view (obviously ideally a path doesn't have to keep repeatedly testing what kind of path it is). But as an example the file you linked makes an assumption that the only valid absolute filepath on Windows is one that starts with a drive letter. Which is not true. It also makes an assumption that It makes an attempt to distinguish between the different namespaces. As in, it recognizes So it's the inconsistencies that is problematic. What I'm asking for is that any path out of the functions are semantically and syntactically valid.. |
@hasufell so having read the proposal, (I believe that I've discussed this with @hvr before) I really like that the filepaths on Windows are represented as Utf16. This will save an immense amount of work.. The only thing I am wondering about is whether The rational is that today whenever a native Windows path is used I can't assume that each manipulation by filepaths keeps a valid path. Which means at the usage point I have to ensure valid. But if I can assume that usages of afp keeps them valid that'll save a lot of processing. Of course I don't want that processing to move into afp (so that one has to check what kind of path something is on every command). If not possible then fine, the Utf16 representation is already a major improvement! |
I don't think so. If you want different codepaths, you can use If you write a low-level library based on AFPP, you simply ifdef around the platform and both codepaths use different inner cosntructors abstract-filepath/lib/AFP/OsString/Common.hs Lines 116 to 121 in 2f54c68
You can't mix them up if you're wrapping them inside OsString, it will be a compile error. That's the point.
On unix, only NUL bytes are invalid. Everything else goes. From my research, windows doesn't have a definite answer about what is a valid filepath and it may depend on filesystem, windows API or the phase of the moon. As such I don't think this library should try to enforce such properties. You should be free to pass junk to syscalls if you like so. https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions looks like just conventions, but some invalid paths may still succeed, but then fail in other ways. This is up to user space library to figure out. |
You clearly know more about these things than me, so I'd appreciate a PR. I took |
I split two packages out:
|
I've finished the Win32 migration (only the subset of the functions that had their API changed are different, the rest are re-exports): 5256773 |
CCing @Bodigrim I'll re-iterate and update the state of the efforts briefly. Context
So far, the CLC has "ack'ed" these efforts, but I have no explicit consent from Win32 or unix package maintainers. These will be the first core packages that need to support AFPP (as additional API). The types need to be put somewhere as well, @snoyberg suggested I put temporary haddocks here: http://files.hasufell.de/AFPP/ StatusI believe the core implementation is done. We now have these utility packages that I already put on hackage:
AFPP packages are pretty much done:
I've started some example migrations of my own packages to AFPP:
How to move forwardUltimately, at least After I finish migrating |
@Mistuke ...I'm currently taking a deeper look into windows paths
Can you be more specific? Afais there are these types:
So
Ok, so I think This also aligns with the discussion at haskell/filepath#56 |
I wonder what's the best way forward with I'm exceedingly busy with |
I think there's some code sharing in the test suite, where I had to cut out all things that aren't shortbytestring relevant. Not sure that's a good argument for merging them. It might make sense to have a split. I think small scope is good for PVP, so messing with shortbytestring (which is maybe more likely when it's started to be heavily used as a new dependency of filepath) doesn't impact the version of bytestring. |
Code can be reviewed here: #4
Rendered docs are here:
Several issues for discussion have also been opened here: https://github.com/hasufell/abstract-filepath/issues
ML thread: https://mail.haskell.org/pipermail/libraries/2021-August/031427.html
Original proposal: https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/abstract-file-path
Old discourse thread: https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afpp-in-user-space/2344
The text was updated successfully, but these errors were encountered: