[PATCH] PR libstdc++/83626 Don't throw for remove("") and remove_all("")

[Jonathan Wakely]

On 05/01/18 18:02 +0000, Jonathan Wakely wrote:
>On 05/01/18 10:37 +0000, Jonathan Wakely wrote:
>>On 04/01/18 21:02 -0500, Tim Song wrote:
>>>What if the file to be removed is externally removed between the
>>>symlink_status and the ::remove call? This is probably QoI because
>>>filesystem race, but it seems reasonable to double check errno if
>>>::remove fails and not fail if the failure is due to the file not
>>>existing.
>>
>>Yes, the race makes it undefined, but checking for ENOENT seems
>>reasonable. Thanks for the suggestion.
>
>This makes remove and remove_all handle (some) filesystem races, by
>ignoring ENOENT errors when removing entries or while iterating over
>sub-directories.
>
>It also avoids redundant stat() calls in remove_all, and fixes a bug
>in the return value of the throwing version of remove_all.
>
>Tested powerpc64le-linux, committed to trunk.
>
>I've attached a multithreaded test I used to test the handling of
>filesystem races, but I'm not committing that test.

In Bugzilla the reporter pointed out that the call to symlink_status
in filesystem::remove is now redundant, because handling the ENOENT
case after calling ::remove gives the same result (and is less
vulnerable to TOCTTOU races).

This removes the symlink_status call, and then makes remove_all call
filesystem::remove again instead of ::remove, because doing so doesn't
add an unnecessary symlink_status call now.

Tested powerpc64le-linux, committed to trunk.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 2609 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20180105/f1b16b73/attachment.bin>