Return to Answer

You cannot just disable locking of executable/library files.

Doing so would break quite a few things, because you might cause situations that the OS never expected. (If the developers assumed that a situation is impossible, they might not have written any code to deal with it.)

For example, it could be that the filesystem code simply assumes that there's always at least one link to a file (and therefore space can be freed immediately after deleting that last link) – so if you force it to delete an in-use file, it might result in various kinds of filesystem corruption, like two files using the same disk space.

(The Old New Thing has once written that it actually wouldn't be hard to allow Linux-style file deletion in the WinNT kernel, and that they just haven't done so to avoid some compatibility issues. However, the point remains – you still don't know whether the OS has been prepared for that possibility or not.)

However, you can move or rename in-use files, so make your build process move the existing DLL elsewhere and compile the new one in its place.

You cannot "just" disable locking of executable/library files.

However, you can move or rename in-use files, so make your build process move the existing DLL elsewhere and compile the new one in its place.

It's very possible that they didn't add a hidden switch for it because various parts of the OS assume it'll always be on. For example, it could be that the filesystem code expects that there's always at least one link to a file (and therefore space can be freed immediately after deleting that last link) – so if you force it to delete an in-use file, it might result in various kinds of filesystem corruption, like two files using the same disk space.

That said, The Old New Thing has once written that it actually wouldn't be hard to allow Linux-style file deletion in the WinNT kernel, and that they just haven't done so to avoid some compatibility issues.

You cannot disable locking of executable/library files.

Doing so would break quite a few things, because you might cause situations that the OS never expected. For example, locking allows the filesystem code to assume that there's always at least one link to a file – if you force the OS to delete an in-use file, and the filesystem doesn't know what to do with it, that could result in filesystem corruption or worse.

However, you can move or rename in-use files, so make your build process move the existing DLL elsewhere and compile the new one in its place.

You cannot just disable locking of executable/library files.

Doing so would break quite a few things, because you might cause situations that the OS never expected. (If the developers assumed that a situation is impossible, they might not have written any code to deal with it.)

For example, it could be that the filesystem code simply assumes that there's always at least one link to a file (and therefore space can be freed immediately after deleting that last link) – so if you force it to delete an in-use file, it might result in various kinds of filesystem corruption, like two files using the same disk space.

(The Old New Thing has once written that it actually wouldn't be hard to allow Linux-style file deletion in the WinNT kernel, and that they just haven't done so to avoid some compatibility issues. However, the point remains – you still don't know whether the OS has been prepared for that possibility or not.)

However, you can move or rename in-use files, so make your build process move the existing DLL elsewhere and compile the new one in its place.

You cannot disable file locking. (It would break quite a lot, if you could.) Note that this is not the same as advisory locking, which is just an extra feature – mandatory locking imposed by the OS might be there because the OS wouldn't know how to deal with a situation where a file was deleted but is still in use... It's not locked for the sole purpose of annoying the user.

However, you can move and rename in-use files, so make your build process move the existing DLL elsewhere.

You cannot disable locking of executable/library files.

Doing so would break quite a few things, because you might cause situations that the OS never expected. For example, locking allows the filesystem code to assume that there's always at least one link to a file – if you force the OS to delete an in-use file, and the filesystem doesn't know what to do with it, that could result in filesystem corruption or worse.

However, you can move or rename in-use files, so make your build process move the existing DLL elsewhere and compile the new one in its place.