From: Senjin <senjin@hatchling.org>
To: ntfs3@lists.linux.dev
Cc: almaz.alexandrovich@paragon-software.com,
linux-kernel@vger.kernel.org, Senjin <senjin@hatchling.org>
Subject: [PATCH v2 2/2] fs/ntfs3: fix lseek EINVAL on sparse/compressed files with 64-bit clusters
Date: 13 Jun 2026 20:16:14 -0000 [thread overview]
Message-ID: <6a2dba8e030b48618aa54661@mailersend.net> (raw)
In-Reply-To: <20260613201610.14467-1-senjin@hatchling.org>
When CONFIG_NTFS3_64BIT_CLUSTER is enabled, sbi->maxbytes_sparse is set
to -1. As a signed loff_t this is -1LL, the most negative value. Any
lseek on a sparse or compressed file passes this as maxsize to
vfs_setpos(), which returns -EINVAL whenever offset > maxsize, and
since -1LL is less than any non-negative offset, every seek fails,
including lseek(fd, 0, SEEK_SET).
The intent of -1 here appears to be "no limit" (matching the spirit of
MAX_LFS_FILESIZE assigned to sbi->maxbytes and sb->s_maxbytes in the
same block), but the signed type makes it the minimum instead of the
maximum.
Fix by assigning MAX_LFS_FILESIZE to sbi->maxbytes_sparse in the
64-bit cluster path, consistent with the other two limits set there.
Observed on a 16 TB NTFS volume with 0xFFFFFEFF total clusters compiled
with CONFIG_NTFS3_64BIT_CLUSTER=y. Sequential reads via dd/cp worked
correctly; any lseek call on sparse files returned EINVAL, preventing
archive managers and other tools from random-accessing files on the
volume. The non-64-bit-cluster path correctly sets maxbytes_sparse to
(1ull << (cluster_bits + 32)) - 1, a large positive value.
Signed-off-by: Senjin <senjin@hatchling.org>
---
fs/ntfs3/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c
index XXXXXXX..XXXXXXX 100644
--- a/fs/ntfs3/super.c
+++ b/fs/ntfs3/super.c
@@ -1193,7 +1193,7 @@ static int ntfs_fill_super(struct super_block *sb, struct fs_context *fc)
#ifdef CONFIG_NTFS3_64BIT_CLUSTER
if (clusters >= (1ull << (64 - cluster_bits)))
sbi->maxbytes = -1;
- sbi->maxbytes_sparse = -1;
+ sbi->maxbytes_sparse = MAX_LFS_FILESIZE;
sb->s_maxbytes = MAX_LFS_FILESIZE;
#else
/* Maximum size for sparse file. */
--
2.x
next prev parent reply other threads:[~2026-06-13 20:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260613201610.14467-1-senjin@hatchling.org>
2026-06-13 20:16 ` [PATCH v2 1/2] fs/ntfs3: load ATTR_BITMAP run extents from $MFT extension records Senjin
2026-06-13 20:16 ` Senjin
2026-06-13 20:16 ` Senjin [this message]
2026-06-13 20:16 ` [PATCH v2 2/2] fs/ntfs3: fix lseek EINVAL on sparse/compressed files with 64-bit clusters Senjin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a2dba8e030b48618aa54661@mailersend.net \
--to=senjin@hatchling.org \
--cc=almaz.alexandrovich@paragon-software.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ntfs3@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.