On Sun, 2008-01-27 at 13:29 -0500, Erez Zadok wrote:
> In message <1201457297.7346.27.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>, Trond Myklebust writes:
> >
> > On Sun, 2008-01-27 at 10:55 -0500, Erez Zadok wrote:
> > > NFS shares some traits with stackable file systems. Both have some notion
> > > of "layers": in nfs, it's client -> server -> local f/s; in a stackable f/s
> > > it's upper -> lower.
> > >
> > > I'm trying to understand what are the semantics of NFS when directories are
> > > renamed on the server while a client is trying to use those directories (I
> > > follow a similar behavior in unionfs or other stackable f/s). Consider this
> > > sequence of steps:
> > >
> > > 1. client looks up (or revalidates) directory D1
> > > 2. server renames D1 to D2 (D2 could be anywhere in the tree)
> > > 3. client tries to create file F in (the cached) directory D1
> > >
> > > What happens in the last step? Does the client get an ESTALE or some other
> > > error? Or does it succeed and F gets created in the renamed directory
> > > (D2/F)? Does the behavior differ b/t nfsv2/3/4? Is it described the RFCs
> > > or specs?
> >
> > The general rule is that an NFSv2/v3/v4 client would expect 3 to succeed
> > (provided that the user has the required permissions).
> [...]
>
> And by "succeed", you mean that the new file F will be created in D2, right?
Yes. That is what a posix application would expect.
Trond