memmap-rs: Mmap fails for empty files on Windows

While the current behavior is consistent, I think almost all callers are going to need special handling for the zero-length case to avoid this error, and as a result there are probably a lot of latent bugs out there waiting for someone to trigger them with an empty file. I just realized I have one in my own code, where I check for a number of conditions but forgot to check for this one.

Maybe relevant, there are cases today where Mmap can accept a zero length and successfully deref to an empty slice. It can happen if you have an offset that isn’t a multiple of the page size, so that the real mapping under the covers isn’t empty. So in that particular case, the caller might end up with an even trickier bug, where their empty maps fail only for certain offsets. (This is especially tough because an “is the file empty” check isn’t good enough here. You have to know how your request offset compares to the file length.)

Just ignore this entirely and simply rely on the user that he does not try to mmap special files from filesystems which do not support mmap.

This doesn’t work well for programs that traverse the entire file hierarchy, like rg or tar. It implies that the user may not invoke the program from /, but that’s something plenty of users want to do. I’m sure there are wacky examples of virtual filesystems in places other than /, too, but that’s bad enough.

It seems like the underlying APIs are pretty tightly coupled to the notion that memmapping empty files is an error, and that callers will fall back to normal reading in the face of errors. (Or perhaps that callers won’t try to mmap below a certain size.) If we want to make empty files not an error, it’s suddenly our responsibility to detect when the filesystem is lying to use about a file’s size. And as the old saying goes: If the file system wants to lie to us, then let the file system lie to us.