How do you find the symbolic links to files.

Root Boy Jim rbj at uunet.UU.NET
Fri Dec 14 13:55:13 AEST 1990


In article <1990Dec12.235535.29083 at erg.sri.com> zwicky at erg.sri.com (Elizabeth Zwicky) writes:
>In article <110689 at convex.convex.com> tchrist at convex.COM (Tom Christiansen) writes:
>>I'll boldly state that any *application* (dump programs don't count) that
>>relies on whether or not a block of nulls is or isn't really allocated on
>>the disk is broken, and therefore it doesn't matter if you put in more
>>holes than were there.  Can anyone show me a case where it would break
>>something?

You are correct. Holes and blocks both read as blocks of zeros, so
how could you tell the difference? Most programs won't have access
to the raw (or block) disks, and there are fewer and fewer hackers
who could make any sense of (especially the BSD) filesystem anyway.

The operating system is free to substitute one for the other at any time,
and the user or program would never know the difference.

>... Postulate a program that has data which... [does weird stuff]
>However, that program can now assume that it has enough space to run in.

What are you talking about? The only thing I can think of is quotas.
Yes, it's possible that a program may die because of lack of space,
but I consider this an administrative or environmental problem.

>I must admit that I can't produce any live examples of programs ...

Nuff Said.

>	Elizabeth Zwicky

Oh, BTW to those who supposedly care how big the block size is,
Don't Worry About It. Just lseek when you see a zero and let the
kernel worry about what's big enuf to be a hole.

		WHILE <read a byte> DO
			IF <nonzero> THEN
				<write the byte>
			ELSE
				<seek one byte>
			FI
		DONE

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, and
most database software usually have rebuild programs anyway.
-- 

	Root Boy Jim Cottrell <rbj at uunet.uu.net>
	Close the gap of the dark year in between



More information about the Comp.unix.internals mailing list