Re: boost.log's text_multifile_backend is not performant on windows - perhaps it should be documented?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-03-05 13:15:07

On 3/5/21 3:56 PM, Niall Douglas via Boost wrote:
> On 05/03/2021 10:45, Andrey Semashev via Boost wrote:
> 
>>>> Keeping open files is not only a concern from resource usage
>>>> perspective. It may affect user's experience, as e.g. on Windows he
>>>> won't be able to remove the open files or the containing directory.
>>>
>>> You can delete or rename open files on Windows just fine. It's just
>>> std::ofstream opens files in a way where you can't.
>>
>> But the containing directory remains locked, doesn't it?
> 
> Locked in the sense that it cannot be renamed or deleted, yes.
> 
> The simple workaround is to rename the file out of its directory before
> you delete it, then the containing directory behaves like on POSIX.

But I'm not the one deleting the file. The hypothetical use case is that 
the logging backend keeps the file open for possible future writing and 
the user attempts to delete the file and the containing folder.

> Recent Windows 10 implement "POSIX delete" by renaming the file into a
> magic hidden NTFS folder in the root called \$Extend\$Deleted, and
> marking it as in-process-of-being-deleted. That same technique works
> right back to NT 3.5.

Seems like a workaround rather than a fix, which would have been to 
allow deleting the folder if it only contains files 
in-process-of-being-deleted. Or just get rid of this weird state entirely.

> A file can be capable of execution according to its ACL.
> 
> A file handle can be capable of executing code according to its
> privileges (dwDesiredAccess contains FILE_GENERIC_EXECUTE).
> 
> You can create a file with an ACL not permitting execution using
> lpSecurityAttributes, or use hTemplateFile to clone a security
> descriptor. Or, you can temporarily adjust the current thread's
> impersonation token such that specifying NULL to CreateFile means files
> created by that thread aren't executable. The former is best when you
> can adjust source code, the latter is best when you are calling third
> party code and you want it to create different permissioned files.
> 
> Note that I don't actually know if the Windows default AV is clever
> enough to not deep scan files without Execute ability. I do know it
> specially skips files signed by a whitelist of Microsoft approved
> signing authorities, and it was written by Microsoft themselves who
> suffer the most from it, so your chances are good.

I suppose, an argument can be made "what if the user changes permissions 
later and tries to execute the file?" From that perspective, the 
antivirus should be scanning everything always.