On 10/9/24 9:43 PM, Jeremy Allison wrote:
On Wed, Oct 09, 2024 at 08:54:12PM +0200, Ralph Boehme wrote:On 10/8/24 5:16 PM, Jeremy Allison wrote:It was done as part of the SMB1 extensions - trying to "pass-through" allpossible POSIX open flags. Just remove it.ok.But then we still need a way to pass O_APPEND over the wire with SMB3 POSIX and we're currently lacking a sane way it seems.What about using one bit of the 17 reserved bits in<https://www.samba.org/~slow/SMB3_POSIX/ fscc_posix_extensions.html#posix-mode>There are more possibly interesting open flags though and I wonder whether packing all of this into those 32 bits is a good idea, but the alternative of changing the SMB2_CREATE_CONTEXT request to add a new field "OpenFlags" is not really a great looking option either.SMB1/2/3 has FILE_APPEND_DATA. From the definition of NtCreateFile (the NT kernel system call).https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf- winternl-ntcreatefile"If only the FILE_APPEND_DATA and SYNCHRONIZE flags are set, the caller can write only to the end of the file, and any offset information on writes to the file is ignored. However, the file is automatically extended as necessary for this type of write operation."Can we just map (access_mask (FILE_APPEND_DATA|SYNCHRONIZE)) == (FILE_APPEND_DATA|SYNCHRONIZE))to O_APPEND, regardless of POSIX mode ?
Hm, interesting findBut I guess this won't help as with POSIX you can open() a file with O_APPEND but then still call pread/pwrite on the resulting fd.
However, if we require SMB3 POSIX clients to map O_APPEND to an access_mask of *only* FILE_APPEND_DATA|SYNCHRONIZE, pread/pwrite would fail as the handle lacks FILE_READ_DATA/FILE_WRITE_DATA. Right?
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
