From: "'Bruce Fields'" <bfields@fieldses.org>
To: Frank Filz <ffilzlnx@mindspring.com>
Cc: "'Kernel NFS List'" <linux-nfs@vger.kernel.org>,
"'Ganesha NFS List'" <nfs-ganesha-devel@lists.sourceforge.net>
Subject: Re: pynfs updates
Date: Tue, 1 Oct 2013 10:26:01 -0400 [thread overview]
Message-ID: <20131001142601.GG26382@fieldses.org> (raw)
In-Reply-To: <003f01cebe38$75436480$5fca2d80$@mindspring.com>
On Mon, Sep 30, 2013 at 07:54:52PM -0400, Frank Filz wrote:
> > - "Add two SECINFO_NO_NAME tests for
> > SECINFO_STYLE4_PARENT":
> > - SECNN3: is / required to have no parent? (I'd assumed
> > here that it would also be OK to follow the convention
> > that / is its own parent, but I'll admit to not having
> > thought about this much.)
>
> >From LOOKUPP:
>
> 18.14.3. DESCRIPTION
> The current filehandle is assumed to refer to a regular directory or
> a named attribute directory. LOOKUPP assigns the filehandle for its
> parent directory to be the current filehandle. If there is no parent
> directory, an NFS4ERR_NOENT error must be returned. Therefore,
> NFS4ERR_NOENT will be returned by the server when the current
> filehandle is at the root or top of the server's file tree.
OK, fine.
> > - SECNN4: is env.home necessarily unequal to "/"? Would
> > seem better to do the lookup in a subdirectory just to
> > be certain.
>
> Env.home is the directory you specify on the command line, I think the
> presumption is that it is a writeable file system. Pynfs creates tmp and
> tree directories in home (and maybe some files also?). Guess if / was
> writeable, you could specify /, so yea, maybe it should go into tmp.
Sounds good.
>
> A better test might actually be to do LOOKUP down to home and even into tmp,
> looking for a junction, and then do the SECINFO_NO_NAME(parent) on the
> directory handle just across the junction if one was found.
Yeah it'd be nice to check that cross-filesystem case but I don't think
it's necessary (and you still have to deal with the case where a
mountpoint's not found).
If tests at mountpoints were useful perhaps we could pass in a
mountpoint on the commandline. Or add some sort of export-configuration
interface to the serverhelper script and let pynfs setup exports itself.
--b.
next prev parent reply other threads:[~2013-10-01 14:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 18:17 pynfs updates Frank Filz
2013-09-30 22:11 ` Bruce Fields
2013-09-30 23:54 ` Frank Filz
2013-10-01 14:26 ` 'Bruce Fields' [this message]
2013-10-01 14:30 ` 'Bruce Fields'
2013-10-01 15:42 ` Frank Filz
2013-10-01 19:05 ` Frank Filz
2013-10-02 11:36 ` 'Bruce Fields'
2013-10-02 15:58 ` Frank Filz
2013-10-01 18:21 ` Frank Filz
2013-10-01 18:45 ` 'Bruce Fields'
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131001142601.GG26382@fieldses.org \
--to=bfields@fieldses.org \
--cc=ffilzlnx@mindspring.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nfs-ganesha-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.