Skip to content
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

Windows does not like default llfio::open arguments #135

Open
ethindp opened this issue Jun 22, 2024 · 3 comments
Open

Windows does not like default llfio::open arguments #135

ethindp opened this issue Jun 22, 2024 · 3 comments
Labels

Comments

@ethindp
Copy link

ethindp commented Jun 22, 2024

The default flags argument on windows (flag::none) is something windows doesn't like for some reason. On my windows 10 machine, the open succeeds but llfio::read gives me a "not supported" error. Changing flags to flag::multiplexable (at minimum) does work though. A bit uncertain as to why this is being caused, so am curious if it's a bug in llfio or if it's something weird happening when llfio opens the file?

@ned14
Copy link
Owner

ned14 commented Jun 25, 2024

I would be very surprised if the defaults don't "just work" given how much this codebase is used on Windows.

I also traced through the code and I can see no obvious reason why opening a file would give an error.

Can you perhaps give me an example piece of code which fails for you?

@ned14 ned14 added the question label Jun 25, 2024
@ethindp
Copy link
Author

ethindp commented Jun 26, 2024

The opening of the file doesn't fail. The error is delayed until the first read. As soon as llfio::read is called when flags is set to flag::none, windows (at least my version) returns the error Not supported: Not supported: "". I think the most relevant example woudl be the read_entire_file1.cpp example. When I used that example to learn how to implement a file that read into a string, that's when I got that (very odd) error (when I did the actual read). But when I set flag::multiplexable, windows is just fine.

@BurningEnlightenment
Copy link
Collaborator

BurningEnlightenment commented Aug 26, 2024

Can you add procmon traces for the failing and succeeding cases? I could take a look this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants