In article <Pine.SOL.3.96.971206120821.10906B-100000@gold.tc.umn.edu> you write:
> 
> Along with non-block reads there is anouther potentiol problem to
> consider: I was told when I first started using files that read(x) [ there
> is anotuehr parameter for a buffer, but I can't recall read schematics off
> the top of my head]  would ALWAYS read x bytes, and return x.  The only
> exception was when dealing with sockets.  I wrote several programs, for
> class, that relied on this behavor.   However an HSM file system may need
> to block read for a long time, thus if I try to read 1500 bytes, and only
> 500 are avaibal it would return 500 bytes.  There may be programs out
> there that do not handle this situation.  Word needs to get out that
> reling on this feature is about to break programs.  (even if it is only

It wouldn't break anything, because the non-blocking semantics must be
asked for. Programs that don't want those semantics won't ask fo them,
and work the way they always have.

> I don't agree with wanting non-blocking, since it will probably be sued
> for polling, (though I agree there needs to be a way to ask for a file to

We already have non-blocking on other types of file descriptors. Sure,
there's nothing preventing you from polling, but no (well written,
anyway) programs do that -- they use select() or poll(). Previously,
there was no need to support nonblock on files, because file access has
always been guaranteed to be relatively fast and to take a predictable
amount of time. Suddently that isn't true, so some programs will want
to be able to deal with disk files in the same manner that they deal
with other accessed-by-file-descriptor things (sockets, etc.) that have
slow, unpredicatble access times.