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@xxxxxxxxxxxxx".
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.
