On Fri, Feb 14, 2025 at 08:36:25AM -0600, Eric Sandeen wrote: > On 2/13/25 10:02 PM, Darrick J. Wong 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. > > Ah, I see. No, the observable problem was an -EFAULT on the write, > and the file /does/ get created as expected. The test probably is > extraneous to the original bug, because of course open(O_CREAT) and > write(0) are two separate operations. I was just a bit over-eager > when writing the test. <nod> Would you mind resending, but with the rm removed? --D > Thanks, > -Eric > > > (IOWs I think this test is fine, but could the exfat maintainer > > clarify?) > > > > --D > > > >> Thanks, > >> -Eric > >> > >> > > > >
