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
