Subject: Re: [boost] [filesystem] How to remove specific files from a directory?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2016-09-13 15:18:58
On 09/13/16 21:51, Niall Douglas wrote:
> Some might ask why not immediately unlink it in RAM as Linux does?
> Linux historically really didn't try hard to avoid data loss on
> sudden power loss, and even today it uniquely requires programmers to
> explicitly call fsync on containing directories in order to achieve
> sudden power loss safety. NTFS and Windows tries much harder, and it
> tries to always keep what *metadata* the program sees via the kernel
> syscalls equal to what is on physical storage (actual file data is a
> totally separate matter). It makes programming reliable filesystem
> code much easier on Windows than on Linux which was traditionally a
> real bear.
I'm not sure I understand how Windows behavior you described provides
better protection against power loss. If the power is lost before
metadata is flushed to media then the file stays present after reboot.
The same happens in Linux, AFAICT, only you can influence the FS
behavior with mount options.
The irritating difference is that even though the file is deleted (by
all means the application has to observe that), the OS still doesn't
allow to delete the containing folder because it's not empty. I'm seeing
this effect nearly every time I boot into Windows - when I delete the
bin.v2 directory created by Boost.Build. There may be historical reasons
to it, but seriously, if the OS tries to cheat and pretends the file is
deleted then it should go the whole way and act as if it is. Workarounds
like rename+delete are a sorry excuse because it's really difficult to
say where to rename the file in presence of reparse points, quotas and
permissions. And most importantly - why should one jump through these
hoops in one specific case, on Windows? The same goes about inability to
delete/move open files.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk