On 24 August 2016 at 17:40, Greg Kurz <gr...@kaod.org> wrote:
> On Wed, 24 Aug 2016 16:00:24 +0100
> Peter Maydell <peter.mayd...@linaro.org> wrote:
>> Do we also need ".." and "." to be illegal names (for at least most
>> operations)?
> I understand how ".." could be an issue, but I don't for "."... can you
> please elaborate ?
If you try to create, open, etc a file named "." then it won't create a
file named "."; it'll do something wrong instead. So we shouldn't
permit attempts to treat "." as an ordinary filename.
(Basically the rationale is that for Linux the constraints on
file and pathnames are only
* no NULs
* no /
* "." is special
* ".." is special
* can't be the empty string
We should reflect that in our error checking.)
> The spec says:
>
> Directories are created by create with DMDIR set in the per-
> missions argument (see stat(5)). The members of a directory
> can be found with read(5). All directories must support
> walks to the directory .. (dot-dot) meaning parent direc-
> tory, although by convention directories contain no explicit
> entry for .. or . (dot). The parent of the root directory
> of a server's tree is itself.
Yes, walk is the one special case that needs to handle "." and ".."
(because for this operation they have a defined meaning that doesn't
mean "just pass them through to the libc functions").
> So I don't think we should boldly make ".." an illegal name, but
> rather ignore it. Pretty much like doing chdir("..") when the current
> directory is /.
>
> All operations except walk take an existing fid and a single path component.
> A possible fix would be to convert ".." to "" when the fid points to the root
> of the export path. Makes sense ?
What did you want the empty string to mean? (We should probably
also define the empty string as an illegal name).
thanks
-- PMM
