Victor

BTW, if you are considering forcing the compatibility thing at Dokan level, I think simply repeating reads until buffer is filled is going to break potential scenarios where FS is...

@Liryna please see above. You can repro the issue with Mirror if you limit the amount of bytes read to 128 in `ReadFile` implementation.

@Liryna also, see my suggested change instead of your fix, that guards against bad number returned by `bytesRead`. It is nice to have foot guards 😁

@LTRData the guards are against negative values and values that are higher than requested.

From MSDN it sounds like @LTRData is correct  E.g. a file system that serves files should always read the requested amount when possible. IMHO, what should be done is...

@LTRData that's why I propose there should be an option for an implementation to opt out of this behavior. E.g. a property on `IDokanOperations`, or another optional interface, or something...

The problem with the "other way around" is that is just calls for bugs. BTW, the whole conversation should also apply to dokan native repository, because in C standard library...

And to prove my theory: https://github.com/dokan-dev/dokan-sshfs/blob/3577c47f92e6f67be80554a7b1a91a922e627495/DokanSSHFS/DokanOperations.cs#L518 yes, it appears to have this bug.

> .NET Stream reads and C library reads always return the number of requested bytes This is never guaranteed, and maybe true right now on Windows, but actually may not...

I'm sorry, but what you say just doesn't match the documentation that I quoted. Unlike the `ReadFile` documentation I quoted above, `FileStream.Read` doesn't make any guarantees like this. And same...