Re: SMB2 DELETE vs UNLINK

["Pali Rohár" <pali@kernel.org>]

On Tuesday 08 October 2024 11:40:06 Ralph Boehme wrote:
> On 10/6/24 12:31 PM, Pali Rohár wrote:
> > 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).
> 
> interesting. Thanks for pointing these out!
> 
> > 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.
> 
> for SMB3 POSIX this will be the behaviour on POSIX handles so we don't
> need an on the wire change. This is part of what will become POSIX-FSA.
> 
> > 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.
> > 
> > I think that this is something which SMB3 POSIX extensions can use
> > and do not have to invent new extensions for the same functionality.
> 
> same here (taking note to remember to add this to the POSIX-FSA and
> check Samba behaviour).
> 
> -slow

So the behavior when the POSIX extension is active would be same as if
every DELETE_ON_CLOSE and every DELETE_PENDING=true requests would set
those new NT flags FILE_DISPOSITION_POSIX_SEMANTICS and
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE?