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?
