🚀 go-pugleaf

In article <18529@louie.udel.EDU>, new@udel.EDU (Darren New) writes:
> Even better, leave the comment field alone and store the new name in the
> list of blocks the file uses. But since we probably want to not make the
> name so short, we (royal we) would use both the block list and the comment
> field and the date and the protection bits.

Yes.

> actual data blocks.

No. Let's keep soft links small. One block.

> ExNext runs across a soft link to something on a non-mounted volume?
> Do we prompt the user to put in that volume, or what?

Yes.

> Say it is on
> the same volume: how does ExNext tell the user it is a soft link
> without breaking existing software?

It magically turns on a 'link bit' in the protection flags (and magically
turns it off if it's not a link).

> always change ExNext to look for the linked-to file and make NewExNext
> return more status information.

Yes. This is implicit in the idea of links. What to do with the file name
portion of the feild is interesting... magically turn it into the name
of the link or not? I think yes, to avoid confusing directory searchers.

But if you lock it and examine the lock, then you'd get the real name (and
no transparent link bit). You just need an NewExNext that *doesn't* follow
the link and returns the new structure if it is a linke.

> But then what happens when the soft-link
> and the linked-to file are in the same directory? We wind up seeing and
> maybe trying to delete the same file twice?

Depends on just what we do, but in general, yes.

> Should a Lock on a soft-link
> file actually lock the linked-to file also?

Yes.

> If so, what if we really want to lock
> the soft-link?

I can't think of a reason for this, offhand.

> I think this is not quite so easy as it seems. (It never is, is it? :-)

But it's not as complex as it seems.
-- 
Peter "Have you hugged your wolf today" da Silva      `-_-'
...texbell!sugar!peter, or peter@sugar.hackercorp.com  'U`