On Tuesday 08 October 2024 11:40:06 Ralph Boehme wrote: > On 10/6/24 12:31 PM, Pali Rohár wrote: > > 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). > > interesting. Thanks for pointing these out! > > > 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. > > for SMB3 POSIX this will be the behaviour on POSIX handles so we don't > need an on the wire change. This is part of what will become POSIX-FSA. > > > 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. > > same here (taking note to remember to add this to the POSIX-FSA and > check Samba behaviour). > > -slow So the behavior when the POSIX extension is active would be same as if every DELETE_ON_CLOSE and every DELETE_PENDING=true requests would set those new NT flags FILE_DISPOSITION_POSIX_SEMANTICS and FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE?
