chris@mimsy.UUCP (Chris Torek) (09/06/88)
In article <690@super.ORG> rminnich@super.ORG (Ronald G Minnich) writes: > I was not talking about tty devices, rather peter da silva's original >comment questioning stat's not supporting the size field for ttys. >That comment got me to thinking about stat()s lack of generality, >since i had been burned by it once. I think that he was making the same point. Ah. Well, perhaps there should be several more stat fields, like `distance to EOF if known', `number of bytes available without blocking', and so forth. (Note that the first two are not the same! The subject is `read keyboard without stopping' and I had been interpreting this entire discussion from that viewpoint. Please edit the subject line when appropriate.) (Incidentally, all the `on SysV' and `in SunOS 3.x' provisos I named were intended as jabs at SunOS and SysV for botching generality. Naturally I consider 4BSD the One True Unix :-) and tend to ignore the others when making statements about how `Unix' works.) >>On regular files, you are at EOF if your current seek offset (available >>via lseek()) matches the size returned via fstat(). >Only if someone else is not writing? This is irrelevant. >If you are reading a regular file, and someone else is writing, then >there are times when your current seek offset will match the returned >size. You are still not at eof, as someone else has the file open. You are still at EOF. That someone else has the file open is irrelevant. >More data can come along. This is 'nothing available to read, but you >are not at eof'. I.e. tail -f, tail never really does know when it hits >eof- you, peculiar creature that you are, decide for it via ^C :-). But even if *no one* has the file open, someone can open it, append data, and possibly close it again; then you are not at EOF anymore. Any multiprocessing system without mandatory locks has this `feature'. EOF is a fleeting concept. You cannot pin it down save momentarily. >P.S. Does it strike anyone as strange that stdio and level 2 have such >different ideas about eof? Level 2 you can just read right through ^D; >As was pointed out, it is more like an enforced one-read FNDELAY than >anything else. for standard IO, one is enough; you lose it all right there. >The FILE * gets closed for you. False. You must, however, call `clearerr' on the FILE pointer: ... if ((c = getc(fp)) == EOF) { if (ferror(fp)) /* read error */ ... clearerr(fp); /* clobber EOF condition */ } else { ... process ... } -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ted@nih-csl.UUCP (ted persky) (12/13/89)
Here's a strange occurrence that's happening on several of our machines here. When I issue a stat() call on any directory which happens to be a mount point for a partition (as indicated by 'df'), the inode number that comes back is '2', which is identical to the inode of the root directory. 'ls -di' indicates the same thing. Why doesn't it give you the actual inode of the directory? For instance, a stat() of /usr will return '2' for the inode. Issuing an 'ls -il /' gives you the actual inode number of /usr, which is what I want stat() to do. Sincerely, Ted Persky P.S. E-mail would be appreciated. This is kind of urgent. -- Ted Persky phone: (301) 496-2963 Building 12A, Room 2031 uucp: uunet!nih-csl!ted National Institutes of Health Internet: ted@alw.nih.gov Bethesda, MD 20892
gwyn@smoke.BRL.MIL (Doug Gwyn) (12/14/89)
In article <1279@nih-csl.UUCP> ted@nih-csl.UUCP (ted persky) writes: >When I issue a stat() call on any directory which happens to be a mount >point for a partition (as indicated by 'df'), the inode number that comes >back is '2', which is identical to the inode of the root directory. That's what you're supposed to see; it's part of the semantics of mounting. >Issuing an 'ls -il /' gives you the actual inode number of /usr, which is >what I want stat() to do. That's too bad. "ls" merely reports the inumber stored in its directory entry, and that is not altered when a filesystem is mounted on the inode. >P.S. E-mail would be appreciated. This is kind of urgent. It can't be TOO urgent since UNIX has always worked like that.