How do you find the symbolic links to files.

[Dan Bernstein]

In article <114453 at uunet.UU.NET> rbj at uunet.UU.NET (Root Boy Jim) writes:
  [ holes versus allocated blocks of zeros ]
> The operating system is free to substitute one for the other at any time,
> and the user or program would never know the difference.

Bad idea, if only for the reason Elizabeth pointed out: A program should
be able to allocate space on disk and know that it is allocated. This is
important for applications that don't want to deal with EDQUOT or ENOSPC
on every write() (or close() :-)), or that need to write asynchronously
to disk as fast as possible. Many such applications exist; this isn't
just a theoretical problem.

If anything, the system should lean in the direction of more allocation
information, not less. There's no harm in providing stable information.

> Yes, it's possible that a program may die because of lack of space,
> but I consider this an administrative or environmental problem.

I don't care what you call it. I want to (e.g.) tell my sound recorder
``Get ready for fifteen seconds of music.'' It had better reserve space
on disk before doing anything else. You're saying it shouldn't be
allowed to do that.

``But no!'' you say. ``It can just write blocks full of 1s. We're only
talking about 0s.'' Oh? Today you're making allocation untenable for
0-filled blocks. How do we know that tomorrow you won't do the same
thing to 1-filled blocks? And every block the next day? It's not the
particular bit of information hiding that I'm worried about; it's this
general philosophy of hiding details that applications need to see.

> Making this buffered is left to the student as an exercise.  People
> have posted blessed (make holey) copy routines before.  It should
> probably be an option to cp, but it isn't that useful that often,

On the contrary. It's ridiculous that, e.g., core files should explode
on Suns just because you forgot to specify, say, -z.

---Dan