ENOENT vs ESTALE on NFS

It seems safe to catch both ESTALE and ENOENT, right?

It has been over two years. I can't remember the slightest about my
readings on this topic.

We did have problem on NFS on CentOS 5.x, and
I traced down to ESTALE/ENOENT.

I need to refresh my memory and see if
we resolved the problem by catching both.

shenchen

On 2014-09-24
03:16, Barry Warsaw wrote:

> It seems safe to catch both ESTALE and
ENOENT, right?
>
> ** Changed in: flufl.lock
> Status: New => In
Progress
>
> ** Changed in: flufl.lock
> Importance: Undecided =>
High
>
> ** Changed in: flufl.lock
> Assignee: (unassigned) => Barry
Warsaw (barry)
>
> ** Changed in: flufl.lock
> Milestone: None => 2.3
>

> --
> You received this bug notification because you are subscribed
to the bug
> report.
> https://bugs.launchpad.net/bugs/977999
>
>
Title:
> ENOENT vs ESTALE on NFS
>
> Status in An NFS-safe file-based
lock library for Python.:
> In Progress
>
> Bug description:
> This
probably affects many routines in flufl.lock.
> On NFS, one should
expect ESTALE instead of ENOENT, when file is deleted.
>
> However, on
some Linux versions, ENOENT is reported, which is the
> wrong
behavior.
>
> references:
> http://bugs.centos.org/view.php?id=4783
>
http://www.dovecot.org/list/dovecot-cvs/2011-April/018699.html
>
> To
manage notifications about this bug go to:
>
https://bugs.launchpad.net/flufl.lock/+bug/977999/+subscriptions

Cool, thanks. Yeah, sorry it's been so long on this bug. I haven't touched flufl.lock in ages, but I'm now working on an update, and plan to release something new in a few days.

I committed the fix to catch both errors, but if this turns out not to be a good idea, please re-open this bug!