On Sun, Oct 6, 2024 at 5:31 AM Pali Rohár <pali@xxxxxxxxxx> wrote: > > Hello, > > Windows NT systems and SMB2 protocol support only DELETE operation which > unlinks file from the directory after the last client/process closes the > opened handle. > > So when file is opened by more client/processes and somebody wants to > unlink that file, it stay in the directory until the last client/process > stop using it. > > This DELETE operation can be issued either by CLOSE request on handle > opened by DELETE_ON_CLOSE flag, or by SET_INFO request with class 13 > (FileDispositionInformation) and with set DeletePending flag. > > > But starting with Windows 10, version 1709, there is support also for > UNLINK operation, via class 64 (FileDispositionInformationEx) [1] where > is FILE_DISPOSITION_POSIX_SEMANTICS flag [2] which does UNLINK after > CLOSE and let file content usable for all other processes. Internally > Windows NT kernel moves this file on NTFS from its directory into some > hidden are. Which is de-facto same as what is POSIX unlink. There is > also class 65 (FileRenameInformationEx) which is allows to issue POSIX > rename (unlink the target if it exists). > > What do you think about using & implementing this functionality for the > Linux unlink operation? As the class numbers are already reserved and > documented, I think that it could make sense to use them also over SMB > on POSIX systems. > > > Also there is another flag FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE > which can be useful for unlink. It allows to unlink also file which has > read-only attribute set. So no need to do that racy (unset-readonly, > set-delete-pending, set-read-only) compound on files with more file > hardlinks. This is a really good point - but what about mkdir (where we have a current bug relating to rmdir of a file after "chmod 0444 dir" -- Thanks, Steve
