[9fans] file server, dotdot

[9fans] file server, dotdot

[Steve Simon]

Hi,

I have met a strange problem, I have a file server
which mostly works, however when I cd into a deep directory
and then try to cd .. all the way out I get stuck at the
top of my synthetic tree.

What confuses me completely is that pwd reports I am in /n so
the kernel must thing I am in /n - to me this means the mount driver
sould be passing all 9p calls to mntgen rather than to my filesystem.

I am sure its my fault and not a bug in the mount driver but I cannot
see how this can happen - Am I being naïve about how pwd is implemented?

Anyone seen anything like this before?

-Steve

Re: [9fans] file server, dotdot

[Russ Cox]

> I am sure its my fault and not a bug in the mount driver but I cannot
> see how this can happen - Am I being naïve about how pwd is implemented?

Dotdot is still broken; you just have to work a lot harder to
break it.  However, it doesn't sound like you did enough to
do that, so I suspect you're not sending the right qids
back from the walks.

Can you have your server print all the 9P messages 
in an example that doesn't work, and then send the
output?  

Russ

Re: [9fans] file server, dotdot

[Steve Simon]

> do that, so I suspect you're not sending the right qids
> back from the walks.

You are quite correct, I should have looked at the source of
the mount driver to better understand how it determines
a cd ".." has poped back up.

It works fine now and ls -qd is my friend.

-Steve

Re: [9fans] file server, dotdot

[Sam]

> Anyone seen anything like this before?

baron% ls -l /dev/sdC0/../../../../../
d-r-xr-xr-x S 0 dennis dennis 0 Jun 16 19:13 /sdC0
d-r-xr-xr-x S 0 dennis dennis 0 Jun 16 19:13 /sdE0
d-r-xr-xr-x S 0 dennis dennis 0 Jun 16 19:13 /sdF0
--rw-r----- S 0 dennis dennis 0 Jun 16 19:13 /sdctl
--rw-r----- S 0 dennis dennis 0 Jun 16 19:13 /sdstat
baron% cd /dev/sdC0
baron% cd ../../../../
baron% lc
sdC0	sdE0	sdF0	sdctl	sdstat
baron%

Re: [9fans] file server, dotdot

[Russ Cox]

> baron% ls -l /dev/sdC0/../../../../../
> d-r-xr-xr-x S 0 dennis dennis 0 Jun 16 19:13 /sdC0
> d-r-xr-xr-x S 0 dennis dennis 0 Jun 16 19:13 /sdE0
> d-r-xr-xr-x S 0 dennis dennis 0 Jun 16 19:13 /sdF0
> --rw-r----- S 0 dennis dennis 0 Jun 16 19:13 /sdctl
> --rw-r----- S 0 dennis dennis 0 Jun 16 19:13 /sdstat
> baron% cd /dev/sdC0
> baron% cd ../../../../
> baron% lc
> sdC0    sdE0    sdF0    sdctl   sdstat
> baron%

This is exactly the kind of bug I expect Steve has committed:

ethel% ls -qd '#S'
(0000000000000001 0 80) '#S'
ethel% ls -qd '#S/sdC0'
(0000000004300004 0 80) '#S/sdC0'
ethel% ls -qd '#S/sdC0/..'
(fffffffffffff001 0 80) '#S'
ethel% 

Notice that the qid for the root doesn't match the qid
that dotdot gives, so the mount driver doesn't realize
that #S/sdC0/.. is the same path as #S/ (according to
the qids, it isn't!).

There is a fixed devsd.c on sources.

Russ