In message <200311252338.aa05451@salmon.maths.tcd.ie>, Ian Dowse writes:
> In message <200311252122.hAPLMRfE018534@agora.fsl.cs.sunysb.ed u>, Erez Zadok wr
> ites:
> >Hmmm, yes I think that could be a serious problem (esp. since fbsd doesn't
> >have autofs yet). And I think it deviates from "norms" where a cwd is
> >essentially occupying a vnode within the mounted f/s and therefore the f/s
> >shouldn't be unmounted! This is rather bad for users who sit on an nfs mnt
> >point, ls'ing files happily, and then the kernel unmounts the mnt pt, moves
> >their cwd down to the covered (typically empty) vnode, and the poor user's
> >next /bin/ls shows nothing.

>
> Yes, I agree completely - however the question of what to do with
> references to about-to-be-covered vnodes at mount time still remains.
> I'll have to look in more detail at why the checkdirs() approach
> was needed in the first place to see if simply removing it is an
> option.


If you have a cwd on a lower mnt pt before the mount, I'd say it makes
_some_ sense to move it "up" to the mnt pt (root vnode) of the newly mounted
fs. This could be very useful for, say, a login shell.

I say "some" b/c I'm concerned about the possibility that some bad process
(rm -rf) that is just started in an emoty mnt point, all of sudden is moved
up to a vnode full of real files, and that process may happily go on to
delete the files in the newly mounted f/s.

Doing the reverse upon unmount (moving the cwd from upper to lower) sounds
even stranger to me. Why? B/c the process used to see some files and now
it sees none. Where did it all go? This can break applications in all
sorts of unhappy ways.

> Any other approaches I can think of right now for solving this issue
> appear to either extend the original checkdirs() hack, or else just
> replace one kind of undesirable behaviour with another.


My personal philosophy when it comes to a choice b/t several un/desirable
modes of operations is the following:

1. Offer flags/options/whatever for users to pick their desired behavior.

2. Don't break existing "expected" behavior: make that the default mode of
operation.

3. In some cases, it's desirable to change the default behavior to one of
the "new modes". But at least everyone will have a way to get the
behavior they want.

4. Disadvantage: poor programmers/maintainers have to keep several modes of
operation working.

The above won't make everyone happy, but it'd maximize the percentage of
happy users.

> Ian


I guess we first need to find out what were the original reasons for the
change in fbsd. Maybe we can find a way to accommodate the needs for that
change w/o breaking functionality.

Cheers,
Erez.
_______________________________________________
freebsd-fs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"