Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!NSFNET-RELAY!MAIL_SYSTEM From: Mail_System%vaxb.york.ac.uk@NSFNET-RELAY.AC.UK Newsgroups: bit.listserv.minix-l Subject: %% Undelivered Mail %% Message-ID: Date: 16 Jan 90 23:00:00 GMT Sender: Minix operating system Reply-To: INFO-MINIX@UDEL.EDU Lines: 67 Approved: NETNEWS@PSUVM Gateway Comments: To: MINIX-L@vm1.nodak.edu Your mail was not delivered as follows: %MAIL-E-SENDERR, error sending to user ACB5 %MAIL-E-OPENOUT, error opening !AS as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-EXDISKQUOTA, disk quota exceeded %MAIL-E-SENDERR, error sending to user ACB5 -MAIL-E-OPENOUT, error opening !AS as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-EXDISKQUOTA, disk quota exceeded Your original mail header and message follow. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Via: UK.AC.NSFNET-RELAY; Tue, 16 Jan 90 23:00 GMT Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id ag15272; 16 Jan 90 22:54 GMT Received: from cunyvm.cuny.edu by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa27747; 16 Jan 90 22:42 GMT Received: from VM1.NoDak.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP; Tue, 16 Jan 90 17:50:49 EDT Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 3501; Tue, 16 Jan 90 16:16:30 CST Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.03B) with BSMTP id 3491; Tue, 16 Jan 90 16:16:28 CST Date: Sat, 13 Jan 90 02:49:31 GMT Reply-To: INFO-MINIX Original-Sender: Minix operating system Comments: Warning -- original Sender: tag was info-minix-request@UDEL.EDU From: Paul Allen Subject: Re: 1.5.0 upgrade: REPORT + BUGS + PATCHES Comments: To: info-minix@udel.edu To: Multiple recipients of list MINIX-L Sender: MINIX-L%edu.nodak.vm1@edu.cuny.cunyvm In article <363@fwi.uva.nl> croes@fwi.uva.nl (Felix A. Croes) writes: +In article <1990Jan7.205429.5247@chinet.chi.il.us> bill@chinet.chi.il.us (Bill Mitchell) writes: +> +>This is apparently due to some problem below readdir(), so dp->d_name +>isn't returned as expected. Things got complicated pretty fast here. +>Knowing nothing about POSIX stuff, I didn't feel qualified pursue it. +>I did notice that /usr/include/dirent.h had struct dirent.d_name +>declared as "char d_name[1]", which looked suspicious. + ^^^^^^^*^ + +I don't know about POSIX, but it should be at least 14. It was 14 in Minix 1.3, +since file names in directories are 14 bytes long. However, using 14 will cause +problems with numerous incorrect programs which assume that file names in +directories always terminate in \0 (ever tried 1.3 tar?). + +The comment says: /* name of file plus a 0 byte */ , so perhaps 15 should be +used? Does any POSIX wizard know? Well, I'm not a POSIX wizard, but I have tried to figure out the directory access stuff. As I recall, dirent structs get malloc'd with a size that depends on the length of the filename. The 'd_name' identifier is then used as a pointer constant. I don't think the declaration of dirent.d_name is a problem. Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% End of returned mail