Re: SMB2 DELETE vs UNLINK

[Tom Talpey <tom@talpey.com>]

On 12/27/2024 11:32 AM, Pali Rohár wrote:
> 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?

Sure, you may include me, tell them I sent you. :)

Tom.