From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=103.168.172.140 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794712037; b=znjIzB1ba4u/t5vLpvZTT62SC/j04lDgSudb1sUigl1IGFk/YW847DTp0I4uqVWoCzSW tDP5yfJ9nP2jBt4I2Tv3LCEkxtnFQvR1sDgBjBL01s6wznzMAL8xpNnKO5cmw8VblEfPe d1yNRaswBO7Aapb5vghDdP3L4qo0Pbc/zT/dCzy8w/XU3XcyJkhRlZCXiNp1s0ll/z75p mdKM67sjhYLNFYzOXwymcIzfrmQrVOtl7imHtuDF+s1gZBUXgVoQCaRhimE1xx9htS/gN pX++wIl0fHTyJhBil9yywVwWepb+7JPhcDpCo24RbWwLw0YB9ghxPkGj1wtROhNcpAA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794712037; h=DMARC-Filter:Received:Received:DKIM-Signature:DKIM-Signature: X-DKIM2-Info:DKIM2-Signature:X-DKIM2-Info:Message-Instance: X-ME-Sender:X-ME-Received:X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID: Received:From:To:Cc:Subject:Date:Message-ID:X-Mailer:In-Reply-To: References:MIME-Version:Content-Transfer-Encoding; bh=gKN6VwWTajjvlUFrRVGdiB8bfxUd1ncQwyi3goNdenM=; b=W2mCDd6F0T5RGfjLzIKkebpnnFVO+daT4vGywhUw2/CKqhHAjfgVBg2sNZOPIR4MEp/Q 0ua6MZZmZwBt06J88kCdcAlUpzFZK3f5isR1hbVJlYMiNJhtZi8tp1R9+p8takmP64AH3 m39CpzmUtw5nzjOBisRiUvzLYLalMKK+2JCOzq99nsuPX+0LQVRIlaPv2g9RH7s/KXl96 LoJR8peN0tgi0uzR7pEEzzoFePQJhIrjQthvSRTi1MIgMPE0YRuK1Rn7FFrcBZicvww9f dT/8x15khOUEDfjHaNdF6UkidNofZ1WSPfbMVv7jc8g31lTtUhDJtxfWxhjNBOPFfaw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=fastmail.org; spf=pass smtp.mailfrom=fastmail.org; dkim=pass header.d=fastmail.org header.i=@fastmail.org header.a=rsa-sha256 header.s=fm3 header.b=KJABPBQL; dkim=pass header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=C+T1zwq7; arc=none smtp.remote-ip=103.168.172.140 Received: from flow-a5-smtp.messagingengine.com (flow-a5-smtp.messagingengine.com [103.168.172.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5718606A32D for ; Sun, 15 Nov 2026 03:07:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org E5718606A32D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fastmail.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fastmail.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=fastmail.org header.i=@fastmail.org header.a=rsa-sha256 header.s=fm3 header.b=KJABPBQL; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=C+T1zwq7 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailflow.phl.internal (Postfix) with ESMTP id 19F5D1381D6B for ; Sat, 14 Nov 2026 22:07:16 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sat, 14 Nov 2026 22:07:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.org; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1794712036; x= 1794719236; bh=gKN6VwWTajjvlUFrRVGdiB8bfxUd1ncQwyi3goNdenM=; b=K JABPBQLg5NoVSoqI5rAeD+skAVRekxAf+DU/sDQcSDo/hJFgvZ95P/eANzp9iQLF UAZ2B9xkDcsQY8iO/CYdG5kbEG/g8ahFsvSXdH9Yt3zkKI5EduBmZwdie/PwJuYN pr1nB0wwaTyAblHINm1kduiiToh1n4/j/pmnDr6jrVEOL7vuhvQtnl4HrOD0i+Qz VJNI9Qs7Z7g/sV1OgO+07SQFs26pkiTSP3Vs60Gkl3NfIhLPjnQ+GIU3l5ZcSMYY 6BUrfLEmvcHATBcpnr0Sd/AgOFMyv61EQ6sM1H/SQz550508xTh/pdmQHOStFSC0 jPBnhFmy4QnsJpm+0UlzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1794712036; x=1794719236; bh=g KN6VwWTajjvlUFrRVGdiB8bfxUd1ncQwyi3goNdenM=; b=C+T1zwq7icCIFknb3 BIG4jj7WX4TMmdwIUWJHKWSC5MP5FgSOyj6ns0HOXIH2T5YPfN1pXKHLvRJTcCXF 4RAfPlQFyaDVvKQjalvWxA4LjJ/6qVhuc95J9QdhnzKhyqGYbskG4iu3zE191pxw WwDwbbTMZ9727IA7maRC0f7969JGpM6O0GDPLjigmcmkhji8OdG0q35gF+hW194f 3C6eO2tZZstn27vPqTyWBu8Kl65YabNpMXiXmJOgt3UinjDRAwVd6HRY84Qb8gEy JCXoIx71tjY+5Gw+8DNq279NyDAebk1uTlroKTom4Wr16JwSv/Q0lnbxelj1fm4V PzmoA== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-09; repo=github.com/dkim2wg/interop; date=2026-11-03; sw=lmtpprox; action=sign d=fastmail.org a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1794712036; d=fastmail.org; mf=PGljYkBmYXN0bWFpbC5vcmc+; rt=PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+; s=fm3:rsa-sha256:fGB9sKS2ZxxPOu6Jey38fGkUPxbp6hBqcsK8kGJlqVImAoN L/KJ21aAbad4UFRpq7y2f+Rmw5qyJqeQhWuGyzj/gz1iu4XkWsPibA1gHbgVW9BD Yuaa+kgDzPzxt3nngOcwR3327YK/YmWGiLMuKXsQfNNcf6IjDPrnoJV6Ap8N3ugW nLZNqxgk3Yj4/di0UfOwevfEpFUXT/POcWMbZEKiISWWsgA3FUdoUBE7ESheq/ac 6E39KF/+S/Wk0lgLq7vzn+WoC2QpTnh+SwZnQpB6jNlQD/5WIDtaZdn0m5r1JQgN ufwwmoPzYuboRZHUljjPNP7oTbDzEzbpoLHlnAA==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-09; repo=github.com/dkim2wg/interop; date=2026-11-03; sw=lmtpprox; action=mi-m=1; hc=11; hn=cc,content-transfer-encoding,date,feedback-id,from, in-reply-to,message-id,mime-version,references,subject,to; Message-Instance: m=1; h=sha256:qU66T9RqzEc/y2kIWw23BwyWdGtBWvSxZnwtdXiF8Ss=:hXDVL1qdwuzv6gV0BtJj9GTi8M/VnQk4yRzSODQdsqo=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTEmAQAs53JP0iZyMPv0h/fG6Xq16Gu2IYoashXOzhNO9jFCRsH4vMrd+HZz7QG80G 9XhEriyQdLjPfnGHNVzSfRbiMNADgBJkGTmYdzQg/vxpb/wvvP8bfHkAzsiuWXXygOlWkf 8yOfk8yvUc+0YjzWoLH9/Y/8zqLIw2ufdO6YEWSAdyodgZOLx1g4CdK1+4TLpE0P7nlmK4 YmfuypoXYRoTraxv4pu5WGIiIJVVDtZCpbG5ixSkiq56zVHcMIL1lQANdEtfF5W/6s9fpr KuRExUlT6YMw/i1oNIayOom1b2SOCwpnP0D6f9fOqlX7BbTtzJEemPUPG/IXd/S/3ht8bb 4Kk1LQ3R5/ChSaxB7RUpXQG8F/Df1I8fcwi5XBzV7C5p1dthAuiFkypzNAvOqUeX2Yu30H x0IJW2SjmJ0UdRDEmXGeHv0ciT8o4l14rVtyczokKTn9rHM01YyZCof+AKxfKXjiAd1bPR 92kXs7krOYyB1KFSiURKrzduMoxwwFgOECrDphX48ku432g25T3pxzoycmc16eaxW+V2Hl mAkJ3oWwm+xaXPEv9Rfkvgenmd9S7R8B3hJB00qhe2ACWUKTOST0tlo3bp8XeeJjQ7lK8e SULpw6jkvdhidJl/Xz4D4u+Edd0y7FY0FJaNbHTS0eDKJp864MJPY5cRxbYg X-ME-Proxy: Feedback-ID: ib53e4b78:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 14 Nov 2026 22:07:13 -0500 (EST) From: Ian Bridges To: koray.fra@gmail.com, linkinjeon@kernel.org Cc: senozhatsky@chromium.org, tom@talpey.com, chenxiaosong@chenxiaosong.com, hyc.lee@gmail.com, linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, Ian Bridges Subject: Re: [PATCH v2] ksmbd: decode and honor DOS attribute validity flags Date: Sat, 14 Nov 2026 21:07:07 -0600 Message-ID: <20261115030707.2275633-1-icb@fastmail.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: <20261114012736.639171-1-koray.fra@gmail.com> <20261114160332.2228435-1-icb@fastmail.org> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Sun Nov 15, 2026 at 2:34 AM CET, koraynilay wrote: > Hello, so I should include the legacy handling in this same patch and > separate the bugfix for sparse/compression in another one? One option might be to keep it all in this patch, with a few changes so that it stays compatible with the xattrs older ksmbd has already stored. When sparse or compression updates an existing xattr, it keeps the creation time, but ndr_decode_dos_attr() discards the flags. The writer then stores the time with only XATTR_DOSINFO_ATTRIB set. Checking CREATE_TIME on read would hide creation times that ksmbd reports today. Your changes to decode the flags and keep the existing fields are useful. On top of those, something like this might work. - Read the stored attributes unconditionally, including a value of 0. Samba also reads the attributes without checking ATTRIB. - Use a non-zero stored creation time even when CREATE_TIME is clear, and fall back to the filesystem timestamp when it is 0. A comment could explain that older ksmbd writers lost the flag. - When rewriting an xattr, preserve the other fields and flags, set ATTRIB, and restore CREATE_TIME if the time being written is non-zero. > The problem I had found when trying this approach (I originally wanted > to send PATCH 1/2 to fix sparse/compression and 2/2 for the decode/read > fixes) is that with only the sparse/compression patch applied, ksmbd > clobbers the time on reading by reporting 0, since it doesn't check > the flags and reads the timestamp anyway. With the reader change in the same patch, a creation time of 0 would select the filesystem timestamp. That handles attribute-only xattrs, but it would not make the writer change safe to apply on its own. > Please tell me if I wasn't clear, this patch/bug is quite confusing for > me since it touches a few bugs and they all depend on each other. > (And one fix introduces another bug fixed by the next fix). Keeping the current no-xattr initialization would avoid that ordering problem altogether. We could fix preservation of existing xattrs here and consider changing newly written xattrs separately. It might also be best to leave changes to ITIME validity policy out of this fix. I don't think ksmbd uses the itime for anything it reports, so those changes would not affect this bug. Namjae, would accepting a non-zero creation time despite a missing flag be a reasonable compatibility rule for existing ksmbd xattrs? Thanks, Ian