On Sunday 06 October 2024 23:18:28 Steve French wrote: > 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" I'm not sure what is doing "chmod 0444 dir". It is setting SMB/NT read-only attribute? If yes then FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE sounds like can be something useful. But anyway, I think that such bug could be fixed by sending SMB2 compound of following SMB2 commands: * CREATE with DELETE desired access without DELETE_ON_CLOSE * SET_INFO with clearing READ_ONLY attribute * SET_INFO with setting DELETE_PENDING * SET_INFO with setting READ_ONLY attribute * CLOSE CREATE with DELETE_ON_CLOSE fails on object with READ_ONLY attr, so CREATE(open) has to be called without it. First SET_INFO will try to remove the protection, to allow second SET_INFO to set DELETE_PENDING flag. In case setting of it will fail, the third SET_INFO will restore the protection. Has SMB2 something like transaction support? NT kernel and its NTFS subsystem provides transaction FS operations for applications. And I think that Cygwin is using those FS transactions for race-free implementation of removing file with read-only attribute.
