Re: SMB2 DELETE vs UNLINK

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

On Friday 27 December 2024 11:21:49 Tom Talpey wrote:
> On 12/25/2024 9:47 AM, Pali Rohár wrote:
> > On Sunday 06 October 2024 12:31:27 Pali Rohár 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.
> > > 
> > > I think that this is something which SMB3 POSIX extensions can use and
> > > do not have to invent new extensions for the same functionality.
> > > 
> > > 
> > > [1] - https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ne-wdm-_file_information_class
> > > [2] - https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/ns-ntddk-_file_disposition_information_ex
> > > [3] - https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_rename_information
> > 
> > And now I figured out that struct FILE_FS_ATTRIBUTE_INFORMATION which
> > has member FileSystemAttributes contains new documented bit:
> > 
> > 0x00000400 - FILE_SUPPORTS_POSIX_UNLINK_RENAME
> > The file system supports POSIX-style delete and rename operations.
> > 
> > See Windows NT spec:
> > https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_file_fs_attribute_information
> > 
> > Interesting is that this struct FILE_FS_ATTRIBUTE_INFORMATION is
> > available over SMB protocol too but bit value 0x00000400 is not
> > documented in [MS-FSCC] section 2.5.1 FileFsAttributeInformation:
> > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/ebc7e6e5-4650-4e54-b17c-cf60f6fbeeaa
> > 
> > So it really looks like that POSIX unlink is prepared for SMB, just is
> > not documented or implemented in Windows yet.
> > 
> > Maybe somebody could ask Microsoft documentation team for more details?
> We absolutely should do this, if the bit is visible remotely then it's
> an obvious omission. If it can be set remotely, even better.

Now I check that Windows Server 2022 via both SMB3.1.1 FileFsAttributeInformation
and via SMB1 QUERY_FS_INFO/FS_ATTRIBUTES announce the 0x00000400 bit for
FILE_SUPPORTS_POSIX_UNLINK_RENAME.

See other email in this tread, I was able to send POSIX UNLINK as
FILE_DISPOSITION_POSIX_SEMANTICS via SMB1, but not over SMB3.1.1
(but it is possible that I did it in wrong way).

> Feel free to raise the issue yourself! Simply email "dochelp@microsoft.com".
> Send as much supporting evidence as you have gathered.
> 
> Tom.

Ok. I can do it. Should I include somebody else into copy?