RE: Found one culprit of -50 errors
Ngo, Hoc <hngo <at> snapserver.com>
2002-05-02 21:26:16 GMT
I'd like to update on this bug.
I captured network trace of copying my Illustrator 10 folder from
Mac OS X to a Mac OS 9 server. I got the same EOF error as in
the case with Netatalk 1.5.2 server, but the copy process
Other than the EOF error and a number of -5018 errors (object not found),
which were expected, I did not see anything unusual in the
Netatalk network trace. All the client requests had consecutive DSI
sequence numbers; i.e., no frames were missing.
So this bug is elusive. I'm still working on it.
> -----Original Message-----
> From: Daniel E. Lautenschleger [mailto:dan <at> bocklabs.wisc.edu]
> Sent: Tuesday, April 30, 2002 5:31 AM
> To: Ngo, Hoc
> Cc: netatalk-devel
> Subject: Re: [Netatalk-devel] Found one culprit of -50 errors
> I think it's great that we've finally got some solid
> information regarding
> the -50/OS X issue. This has been driving me (and others) nuts.
> I'm all for a temporary fix, but is this a fault of OS X or
> not? If it is,
> should we not submit a bug report to Apple?
> I'd like to here from the major code commiters what they think.
> Good job, Hoc!
> On Tue, 30 Apr 2002, Ngo, Hoc wrote:
> > Hi all,
> > To reproduce -50 errors, I tried copying a number of
> > folders inside the Applications folder from my OS X to
> > Netatalk 1.5.2 server. To my dismay most folders
> > failed for -50 errors.
> > I captured network traffic and found out these -50
> > errors were EOF when my Mac client tried to read the
> > resource fork without writing resource data to it first.
> > Following is the summary of my network trace:
> > Frame Description
> > ... ............
> > 72 AFPD Request: Get FileDirParams for "Adobe
> Illustrator 10" on vol id 0
> > 73 AFPD Reply: Attrib=0x0, dir id 20, fileno
> 973078657, datalen 0,
> > resrc len 0, ...
> > 74 AFPD Request: Open resource fork "Adobe Illustrator
> 10", access mode
> > 0x03, ...
> > 75 AFPD Reply: Open fork success, orefnum = 0x0300
> > 76 AFPD Request: Read resource fork, orefnum = 0x0300,
> offset 0, len 761
> > 77 AFPD Reply: Read error: result = -5009 (EOF error)
> > 78 AFPD Request: Write resource fork, orefnum = 0x0300,
> offset 0, len 761
> > 79 DSI Write Request continued
> > ... ....
> > 81 AFPD Reply: Write success, bytesWritten: 761
> > ... .....
> > In summary, the server informed the Mac OS client that
> > both data and resource forks were empty at frame 73.
> > However, the client still proceeded to open the resource fork
> > anyway and then tried to read 761 bytes from it.
> > Because the resrc fork was empty, the client got error -5009,
> > which it translated to -50, I believe. Although the read failed,
> > the client still proceeded to write 751 bytes. This time it
> > I checked the sequence numbers in these frames and they
> were correct.
> > Indeed, open occurred before read, read before write!
> > I think the order was wrong. The client should have written first
> > before reading back.
> > In fact, in cases where the copy process was successful, my network
> > trace showed the correct ordering: open, write, then read.
> > As for the error, you can go to fork.c, search for "AFPERR_EOF".
> > For every EOF error, insert a debug syslog() statement.
> > Then you will see this EOF occurs when offset = 0 and filesize = 0.
> > I think there may be a racing condition somewhere that caused
> > the read request to arrive before the write.
> > Now that I know this type of error, I think it is impossible
> > to fix on the server side. Netatalk does exactly what the
> > protocol says.
> > However, for temporary relief to Mac users, can we, somehow,
> > detect this bad read/write ordering by checking the following
> > condition on each read:
> > offset = 0, filesize = 0, bytesToRead > 0
> > or more generally:
> > offset + bytesToRead > filesize
> > and infer that the client does not intend on reading ahead
> > of writing (hopefully). If this is the case, we will fork
> > another process to handle a delayed read. If the next request
> > the parent process receives is
> > 1) a write request:
> > the child process will wait for the write to complete,
> > then proceeds to read the data and reply to client,
> > then dies.
> > 2) not a write request:
> > Then the child process will go ahead to reply EOF error to
> > the client, then go away.
> > 3) If the parent process does not receive the next request
> > in a reasonable of time, we will do as step 2.
> > Anyone has a better idea?
> > Thanks
> > Hoc
> > _______________________________________________
> > Netatalk-devel mailing list
> > Netatalk-devel <at> lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/netatalk-devel