On Fri, Feb 14, 2025 at 1:02 PM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Thu, Feb 13, 2025 at 09:17:28PM -0600, Eric Sandeen wrote: > > On 2/13/25 2:50 PM, Eric Sandeen wrote: > > > On 2/13/25 1:51 PM, Darrick J. Wong wrote: > > > > ... > > > > >>> +rm -f $TEST_DIR/testfile.$seq > > >>> +$XFS_IO_PROG -f -c "pwrite 0 0" $TEST_DIR/testfile.$seq > > >>> +test -f $TEST_DIR/testfile.$seq || _fail "file not created" > > >> > > >> When does the file not get created? > > > > > > In some unknown error case? ;) > > > There's probably no reason for that test, though of course > > > it's still expected to pass. > > > > > > In the various discussions of the exfat bug scattered around > > > the internet people kept pointing out that "well, the file does > > > get created" so I probably had that on my mind. > > > > To put a finer point on it, because I can't tell for sure - are > > you asking me to take that test out? > > Nah, I was just wondering if there was something about the buggy exfat > code that either prevented the file from being created, or if the bug > was that the empty file got deleted after the zero-byte pwrite and I > misunderstood what's going on. > > (IOWs I think this test is fine, but could the exfat maintainer > clarify?) File was not deleted due to a bug in exFAT. It has caused a misunderstanding because exFAT returns an incorrect errno (-EFAULT) from zero length write. Thanks. > > --D > > > Thanks, > > -Eric > > > >
