On Mon, Oct 7, 2024 at 1:48 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > > 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? "chmod 0444" (since that has the effect on Linux local fs of making a file "read only) has the effect of setting the read only file attribute for cases when ACLs are not supported (e.g. cifsacl or modefromsid), or where POSIX/Linux extensions are not supported -- Thanks, Steve
