Ian Kent wrote:
> So far only David commented about using ENOENT rather than EREMOTE.
>
> I prefer ENOENT for this case myself and he didn't object when I
> explained why, David, any concerns?
Not really - it just seems EREMOTE is a better fit since there is something
there, we're just not allo
On 24/08/17 19:03, Michael Kerrisk (man-pages) wrote:
> Hi Neil,
>
> On 24 August 2017 at 06:07, NeilBrown wrote:
>> On Wed, Aug 23 2017, Ian Kent wrote:
>>
>>>
>>> That inconsistency has bothered me for quite a while now.
>>>
>>> It was carried over from the autofs module behavior when automount
Hi Neil,
On 24 August 2017 at 06:07, NeilBrown wrote:
> On Wed, Aug 23 2017, Ian Kent wrote:
>
>>
>> That inconsistency has bothered me for quite a while now.
>>
>> It was carried over from the autofs module behavior when automounting
>> support was added to the VFS. What's worse is it prevents t
On Mon, Aug 14 2017, NeilBrown wrote:
> On Fri, Aug 11 2017, Trond Myklebust wrote:
>
>> On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
>>> Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock
>>> flag and introduced the d_weak_revalidate dentry operation instead.
>>> We duly
On 24/08/17 12:07, NeilBrown wrote:
>
>
> The more precise details, that automount action for indirect automount
> points is not triggered when the 'browse' option is used, is probably
> not necessary.
>
> Ian: if you agree with that text, and Michael doesn't provide alternate
> evidence, I'll s
On 24/08/17 12:07, NeilBrown wrote:
> On Wed, Aug 23 2017, Ian Kent wrote:
>
>>
>> That inconsistency has bothered me for quite a while now.
>>
>> It was carried over from the autofs module behavior when automounting
>> support was added to the VFS. What's worse is it prevents the use of
>> the AT
On 24/08/17 11:21, NeilBrown wrote:
> On Wed, Aug 23 2017, Ian Kent wrote:
>
>> On 23/08/17 10:32, Ian Kent wrote:
>>> On 23/08/17 09:06, NeilBrown wrote:
On Mon, Aug 21 2017, Ian Kent wrote:
>>
>> A mount isn't triggered by kern_path(pathname, 0, &path).
>> That '0' would ne
On Wed, Aug 23 2017, Ian Kent wrote:
>
> That inconsistency has bothered me for quite a while now.
>
> It was carried over from the autofs module behavior when automounting
> support was added to the VFS. What's worse is it prevents the use of
> the AT_NO_AUTOMOUNT flag from working properly with
On Wed, Aug 23 2017, Ian Kent wrote:
> On 23/08/17 10:32, Ian Kent wrote:
>> On 23/08/17 09:06, NeilBrown wrote:
>>> On Mon, Aug 21 2017, Ian Kent wrote:
>>>
>
> A mount isn't triggered by kern_path(pathname, 0, &path).
> That '0' would need to include one of
> LOOKUP_PARENT | LO
On 23/08/17 10:54, Ian Kent wrote:
> On 23/08/17 10:40, Ian Kent wrote:
>> On 23/08/17 10:32, Ian Kent wrote:
>>> On 23/08/17 09:06, NeilBrown wrote:
On Mon, Aug 21 2017, Ian Kent wrote:
>>
>> A mount isn't triggered by kern_path(pathname, 0, &path).
>> That '0' would need to
On 23/08/17 10:40, Ian Kent wrote:
> On 23/08/17 10:32, Ian Kent wrote:
>> On 23/08/17 09:06, NeilBrown wrote:
>>> On Mon, Aug 21 2017, Ian Kent wrote:
>>>
>
> A mount isn't triggered by kern_path(pathname, 0, &path).
> That '0' would need to include one of
> LOOKUP_PARENT | LOOKU
On 23/08/17 10:32, Ian Kent wrote:
> On 23/08/17 09:06, NeilBrown wrote:
>> On Mon, Aug 21 2017, Ian Kent wrote:
>>
A mount isn't triggered by kern_path(pathname, 0, &path).
That '0' would need to include one of
LOOKUP_PARENT | LOOKUP_DIRECTORY |
LOOKUP_OPEN | LOOKUP_CR
On 23/08/17 09:06, NeilBrown wrote:
> On Mon, Aug 21 2017, Ian Kent wrote:
>
>>>
>>> A mount isn't triggered by kern_path(pathname, 0, &path).
>>> That '0' would need to include one of
>>> LOOKUP_PARENT | LOOKUP_DIRECTORY |
>>> LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT
>>>
>>> to trigger
On Mon, Aug 21 2017, Ian Kent wrote:
>>
>> A mount isn't triggered by kern_path(pathname, 0, &path).
>> That '0' would need to include one of
>> LOOKUP_PARENT | LOOKUP_DIRECTORY |
>> LOOKUP_OPEN | LOOKUP_CREATE | LOOKUP_AUTOMOUNT
>>
>> to trigger an automount (otherwise you just get -EISDIR)
On Mon, Aug 21 2017, Ian Kent wrote:
> On 21/08/17 14:23, NeilBrown wrote:
>> On Fri, Aug 18 2017, Ian Kent wrote:
>>
>>> On 18/08/17 13:24, NeilBrown wrote:
On Thu, Aug 17 2017, Ian Kent wrote:
> On 16/08/17 19:34, Jeff Layton wrote:
>> On Wed, 2017-08-16 at 12:43 +1000, NeilBr
On 21/08/17 14:23, NeilBrown wrote:
> On Fri, Aug 18 2017, Ian Kent wrote:
>
>> On 18/08/17 13:24, NeilBrown wrote:
>>> On Thu, Aug 17 2017, Ian Kent wrote:
>>>
On 16/08/17 19:34, Jeff Layton wrote:
> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
>> On Mon, Aug 14 2017, Jeff Lay
On Fri, Aug 18 2017, Ian Kent wrote:
> On 18/08/17 13:24, NeilBrown wrote:
>> On Thu, Aug 17 2017, Ian Kent wrote:
>>
>>> On 16/08/17 19:34, Jeff Layton wrote:
On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
> On Mon, Aug 14 2017, Jeff Layton wrote:
>
>> On Mon, 2017-08-14 at
On 18/08/17 14:47, Ian Kent wrote:
> On 18/08/17 13:24, NeilBrown wrote:
>> On Thu, Aug 17 2017, Ian Kent wrote:
>>
>>> On 16/08/17 19:34, Jeff Layton wrote:
On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
> On Mon, Aug 14 2017, Jeff Layton wrote:
>
>> On Mon, 2017-08-14 at 09:
On 18/08/17 13:24, NeilBrown wrote:
> On Thu, Aug 17 2017, Ian Kent wrote:
>
>> On 16/08/17 19:34, Jeff Layton wrote:
>>> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
On Mon, Aug 14 2017, Jeff Layton wrote:
> On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
>> On Fri, A
On Thu, Aug 17 2017, Ian Kent wrote:
> On 16/08/17 19:34, Jeff Layton wrote:
>> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
>>> On Mon, Aug 14 2017, Jeff Layton wrote:
>>>
On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
> On Fri, Aug 11 2017, Jeff Layton wrote:
>
>> On
On 16/08/17 19:34, Jeff Layton wrote:
> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
>> On Mon, Aug 14 2017, Jeff Layton wrote:
>>
>>> On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
On Fri, Aug 11 2017, Jeff Layton wrote:
> On Fri, 2017-08-11 at 05:55 +, Trond Myklebus
On Wed, Aug 16 2017, Jeff Layton wrote:
> On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
>> On Mon, Aug 14 2017, Jeff Layton wrote:
>>
>> > On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
>> > > On Fri, Aug 11 2017, Jeff Layton wrote:
>> > >
>> > > > On Fri, 2017-08-11 at 05:55 +, T
On Wed, 2017-08-16 at 12:43 +1000, NeilBrown wrote:
> On Mon, Aug 14 2017, Jeff Layton wrote:
>
> > On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
> > > On Fri, Aug 11 2017, Jeff Layton wrote:
> > >
> > > > On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
> > > > > On Fri, 2017-08-1
On Mon, Aug 14 2017, Jeff Layton wrote:
> On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
>> On Fri, Aug 11 2017, Jeff Layton wrote:
>>
>> > On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
>> > > On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
>> > > > Funny story. 4.5 years ag
On Mon, 2017-08-14 at 09:36 +1000, NeilBrown wrote:
> On Fri, Aug 11 2017, Jeff Layton wrote:
>
> > On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
> > > On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
> > > > Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock
> > >
On Fri, Aug 11 2017, Jeff Layton wrote:
> On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
>> On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
>> > Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock
>> > flag and introduced the d_weak_revalidate dentry operation inste
On Fri, Aug 11 2017, Trond Myklebust wrote:
> On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
>> Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock
>> flag and introduced the d_weak_revalidate dentry operation instead.
>> We duly removed the flag from NFS superblocks and NFSv
On Fri, 2017-08-11 at 05:55 +, Trond Myklebust wrote:
> On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
> > Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock
> > flag and introduced the d_weak_revalidate dentry operation instead.
> > We duly removed the flag from NFS supe
On Fri, 2017-08-11 at 14:31 +1000, NeilBrown wrote:
> Funny story. 4.5 years ago we discarded the FS_REVAL_DOT superblock
> flag and introduced the d_weak_revalidate dentry operation instead.
> We duly removed the flag from NFS superblocks and NFSv4 superblocks,
> and added the new dentry operatio
29 matches
Mail list logo
