mapped_temp_inode leaking space on windows

[patstew]

On some machines (it doesn't happen to me, but does to one of my colleagues) the space allocated to a mapped_temp_inode on windows doesn't seem to get freed until the machine is rebooted. Successive invokations in separate application instances consume free disk space until none is left, until reboot, whereupon it all comes back. It doesn't seem to matter whether the llfio handle is cleanly destructed or not, it always does get freed for me and not for them when the application is closed/killed.

I'm not sure how to debug this, obviously it's difficult to get windows to tell you anything about a file with no filename. With windirstat they are able to see a corresponding 'Unknown' block on the disk with no path after the handle and application are closed.

The same issue does not occur with mapped_temp_file (which is a fine workaround for our purposes).

Any idea what's going on?

[ned14]

Try restarting the Window virus checker (or any other virus checker).

You may find all that space reappears.

If so, that's a bug in the virus checker not LLFIO unfortunately. They open a handle to do the virus check, but because it's a file with no name they appear to forget to close it.

BTW files without a name on Windows actually do have a name on NTFS! They point into a $Index path or something like that. Basically an internal NTFS path because a file cannot have a path, it needs to have some path to somewhere. So you might also look into your colleague if they're running NTFS or ReFS or FAT or something else.

NT Internals have low level diagnostic tools which can report all open handles on a system. This can be useful to see who is holding open a file to prevent it getting space reclaimed.

This problem does also present on Linux -- I had a bear of a time years ago where Docker for a while held open unlinked files causing disc space exhaustion. Docker eventually fixed itself.Fun times.

[patstew]

We're both only running windows defender, that was my first guess, though I suppose it could be behaving differently for some reason. I will try to find out what's got an open handle to it, thanks for the pointers.