Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 May 2022 04:11:08 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 264196] sysutils/fusefs-ntfs: read(2)ing big files in blocks of 32768 bytes and smaller fails with EINVAL
Message-ID:  <bug-264196-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264196

            Bug ID: 264196
           Summary: sysutils/fusefs-ntfs: read(2)ing big files in blocks
                    of 32768 bytes and smaller fails with EINVAL
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs@FreeBSD.org
          Reporter: danfe@FreeBSD.org
                CC: asomers@FreeBSD.org, freebsd@dussan.org
             Flags: maintainer-feedback?(freebsd@dussan.org)
                CC: freebsd@dussan.org
 Attachment #234168 text/plain
         mime type:

Created attachment 234168
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D234168&action=
=3Dedit
Demo program that does the read(2)

With the recent 14.0-CURRENT (n255230) and fusefs-ntfs-2017.3.23 (UBLIO=3Do=
ff),
I'm frequently getting errors when copying not-very-small files with scp(1)=
 to
remote machines, but not with rsync(1); cat(1)ing file e.g. to /dev/null al=
so
fails.  Running those programs under truss(1) reveals interesting bug: read=
ing
the files on Windows 10 formatted NTFS with block of size 32768 and smaller
(stat(2) returns optimal size of 4096 bytes, which both scp(1) and cat(1) u=
se)
fails after several blocks; rsync(1) uses 262144 and does not fail.  Even m=
ore
interestingly, it does not fail on first couple of blocks and on previously
read ones, i.e. once the file had been read, it can be read again with smal=
ler
block size.  I've written a program to demonstrate this (attached):

$ ls -l xorgproto-2021.5.tbz
-rw-r--r--  1 danfe  wheel  245998 21 =D1=8F=D0=BD=D0=B2.  14:11 xorgproto-=
2021.5.tbz
$ /tmp/a.out xorgproto-2021.5.tbz 32768
using i/o size 32768 (optimal 4096)
read: Invalid argument
1 reads were successful

$ /tmp/a.out xorgproto-2021.5.tbz 32768
using i/o size 32768 (optimal 4096)
read: Invalid argument
3 reads were successful

$ /tmp/a.out xorgproto-2021.5.tbz 32768
using i/o size 32768 (optimal 4096)

$ /tmp/a.out xorgproto-2021.5.tbz -1
using i/o size 4096 (optimal 4096)

I'm not sure if the bug is in the port or fusefs(5) implementation, so I'm
CC'ing Alan in case he might have a clue.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264196-7788>