From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <018601c34030$53e17c00$d2944251@insultant.net> From: "boyd, rounin" To: <9fans@cse.psu.edu> Subject: Re: [9fans] Rstat needs three size fields? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 2 Jul 2003 02:24:40 +0200 Topicbox-Message-UUID: e5406cb2-eacb-11e9-9e20-41e7f4b1d025 Sam asked me: > OK, I've been thinking about this a day now and I'm > not sure what you mean. There shouldn't be any partial > directory entries, right? in the 'old days' directories had a fixed size [2 byte inode number + 14 byte name]. so it was easy. you could cheat and statically allocate and we mainly did 'cos calling malloc was a big no-no, 'cos there was next to no memory and cpu was scarce. then came along BSD which gave us these lunatic long names and a namei() that took years to fix. so you used readdir() and a chunk of crap because just calling read was now _too hard_ -- in fact it was illegal. then we had NFS. and so you had to ask the server to send across some number of directory entries [getdents()] and this sat under readdir(). this was all very fine, but now you had a bunch of library functions and system calls and NFS protocol garbage and you couldn't use read() anymore. in fact _the only place_ the XDR encode/decode code existed for directory entries was _in the kernel_. that stuff was really 'fascinating' ... Brushes with death were described as "fascinating." To be "absolutely fascinated" meant scared witless. -- http://www.air-america.org/Articles/Doole.htm should you have had ultrix and wanted to write a user-mode NFS server you had to either get a protocol analyser, tcpdump, dick around, guess or get hold of the code. [i wrote an NFS version of ftpfs] there was never anything wrong with read(). the proliferation of crap, as a result of BSD long names, added an immense amount of useless baggage. should read() return partial directory entries you are in a world of pain because you have to maintain state so that you can pick up where you left off and try and glue the partials back together. so the solution is to just use read() and return whole directory entries; it simplifies things on both the client and server side. should read return 0, multiply the malloc()'d buffer by 2, realloc() and loop. it helps if you have some side information so that when the read() returns you have a clue of how much stuff is in the buffer, 'cos buffer overruns are not your friend. i suspect the extra size info is 'side information'.