On 20.07.21 16:50, Vivek Goyal wrote:
On Tue, Jul 13, 2021 at 05:07:31PM +0200, Max Reitz wrote:
[..]
The next question is, how do we detect temporary failure, because if we
look up some new inode, name_to_handle_at() fails, we ignore it, and
then it starts to work and we fail all further
On Tue, Jul 13, 2021 at 05:07:31PM +0200, Max Reitz wrote:
[..]
> > The next question is, how do we detect temporary failure, because if we
> > look up some new inode, name_to_handle_at() fails, we ignore it, and
> > then it starts to work and we fail all further lookups, that’s not
> > good. We
So I’m coming back to this after three weeks (well, PTO), and this again
turns into a bit of a pain, actually.
I don’t think it’s anything serious, but I had thought we had found
something that would make us both happy because it wouldn’t be too ugly,
and now it’s turning ugly again... So
On Mon, Jun 21, 2021 at 07:07:19PM +0200, Max Reitz wrote:
> On 21.06.21 17:51, Vivek Goyal wrote:
> > On Mon, Jun 21, 2021 at 11:02:16AM +0200, Max Reitz wrote:
> > > On 18.06.21 20:29, Vivek Goyal wrote:
>
> [snip]
>
> > > > What am I not able to understand is that why we can't return error if
On 21.06.21 17:51, Vivek Goyal wrote:
On Mon, Jun 21, 2021 at 11:02:16AM +0200, Max Reitz wrote:
On 18.06.21 20:29, Vivek Goyal wrote:
[snip]
What am I not able to understand is that why we can't return error if
we run into a temporary issue and can't generate file handle. What's
that
On Mon, Jun 21, 2021 at 11:02:16AM +0200, Max Reitz wrote:
> On 18.06.21 20:29, Vivek Goyal wrote:
> > On Fri, Jun 18, 2021 at 10:28:38AM +0200, Max Reitz wrote:
> > > On 17.06.21 23:21, Vivek Goyal wrote:
> > > > On Wed, Jun 16, 2021 at 03:38:13PM +0200, Max Reitz wrote:
> > > > > On 11.06.21
On 18.06.21 20:29, Vivek Goyal wrote:
On Fri, Jun 18, 2021 at 10:28:38AM +0200, Max Reitz wrote:
On 17.06.21 23:21, Vivek Goyal wrote:
On Wed, Jun 16, 2021 at 03:38:13PM +0200, Max Reitz wrote:
On 11.06.21 22:04, Vivek Goyal wrote:
On Wed, Jun 09, 2021 at 05:55:49PM +0200, Max Reitz wrote:
On Fri, Jun 18, 2021 at 10:28:38AM +0200, Max Reitz wrote:
> On 17.06.21 23:21, Vivek Goyal wrote:
> > On Wed, Jun 16, 2021 at 03:38:13PM +0200, Max Reitz wrote:
> > > On 11.06.21 22:04, Vivek Goyal wrote:
> > > > On Wed, Jun 09, 2021 at 05:55:49PM +0200, Max Reitz wrote:
> > > > > Currently,
On 17.06.21 23:21, Vivek Goyal wrote:
On Wed, Jun 16, 2021 at 03:38:13PM +0200, Max Reitz wrote:
On 11.06.21 22:04, Vivek Goyal wrote:
On Wed, Jun 09, 2021 at 05:55:49PM +0200, Max Reitz wrote:
Currently, lo_inode.fhandle is always NULL and so always keep an O_PATH
FD in lo_inode.fd.
On Wed, Jun 16, 2021 at 03:38:13PM +0200, Max Reitz wrote:
> On 11.06.21 22:04, Vivek Goyal wrote:
> > On Wed, Jun 09, 2021 at 05:55:49PM +0200, Max Reitz wrote:
> > > Currently, lo_inode.fhandle is always NULL and so always keep an O_PATH
> > > FD in lo_inode.fd. Therefore, when the respective
On 11.06.21 22:04, Vivek Goyal wrote:
On Wed, Jun 09, 2021 at 05:55:49PM +0200, Max Reitz wrote:
Currently, lo_inode.fhandle is always NULL and so always keep an O_PATH
FD in lo_inode.fd. Therefore, when the respective inode is unlinked,
its inode ID will remain in use until we drop our
On Wed, Jun 09, 2021 at 05:55:49PM +0200, Max Reitz wrote:
> Currently, lo_inode.fhandle is always NULL and so always keep an O_PATH
> FD in lo_inode.fd. Therefore, when the respective inode is unlinked,
> its inode ID will remain in use until we drop our lo_inode (and
> lo_inode_put() thus
12 matches
Mail list logo