[spatulon]

> Any open file

Any file that was opened without specifying FILE_SHARE_DELETE in the call to CreateFile[1] (the Win32 equivalent of open(2)). Unfortunately, most language runtimes that wrap CreateFile tend not to pass that flag.

[1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...

[xxs]

indeed - also reminds me that languages like go[0] and java[1] did disagree to even attempt using it

[0]: https://github.com/golang/go/issues/32088#issuecomment-53759...

[1]: https://bugs.openjdk.org/browse/JDK-6607535

So to me it's just not there...

[mananaysiempre]

Apparently some parts of this are quite recent, huh[1]:

> jstarks commented on Jun 18, 2019:

> [I]n the most recent version of Windows, we updated DeleteFile (on NTFS) to perform a "POSIX" delete, where the file is removed from the namespace immediately instead of waiting for all open handles to the file to be closed.

[1] https://github.com/golang/go/issues/32088#issuecomment-50285...

[ChrisSD]

Notably Rust's standard library does allow deleting files it opens by default. https://github.com/rust-lang/rust/blob/735bb7e5df185cc24e565...

While full Unix-like behaviour is only available on Windows 10 for the past five or so years, you can still have the old win32 behaviour on older systems (delete once the last file handle is closed).

[nextaccountic]

Can a running executable start with this flag, so that its file can be removed?

[dist-epoch]

Probably not, since Windows uses the executable file as backing for memory mapping.