Bug: notmuch new chokes on dangling symlinks and quits

Bug: notmuch new chokes on dangling symlinks and quits

[Gregor Zattler]

Dear notmuch developers,

notmuch new quits operation if it hit's a dangling symlink:


Error reading file /home/grfz/notmuch2/Mail/findex/cur/123456789.684055.mairix:2,: No such file or directory
Note: A fatal error was encountered: Something went wrong trying
to read or write a file Processed 85 total files in 1s (47
files/sec.)


I consider this to be a bug.  Instead notmuch should simply
ignore the symlink.

This is especially problematic while indexing a huge amount of
mail the first time and notmuch hits the dangling symlink at an
early stage of indexing.


Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: Bug: notmuch new chokes on dangling symlinks and quits

[David Bremner]

Gregor Zattler <telegraph@gmx.net> writes:

>
> I consider this to be a bug.  Instead notmuch should simply
> ignore the symlink.
>

Since there is a test for specifically this behaviour, I'd have to say
it's a design decision you don't agree with, not a bug ;).

In any case, if there is just a few broken symlinks, and you want to
ignore them, you can add them the ignore= line in .notmuch-config

d

Re: Bug: notmuch new chokes on dangling symlinks and quits

[Gregor Zattler]

Hi David,
* David Bremner <david@tethera.net> [26. Jan. 2014]:
> Gregor Zattler <telegraph@gmx.net> writes:
>> I consider this to be a bug.  Instead notmuch should simply
>> ignore the symlink.
>>
> 
> Since there is a test for specifically this behaviour, I'd have to say
> it's a design decision you don't agree with, not a bug ;).

May I ask why this is so?

> In any case, if there is just a few broken symlinks, and you want to
> ignore them, you can add them the ignore= line in .notmuch-config

Thanks, I deleted some, and ignored others.  Insofar my problem is
solved. 

Ciao, Gregor
-- 
 -... --- .-. . -.. ..--.. ...-.-

Re: Bug: notmuch new chokes on dangling symlinks and quits

[Eric]

On Mon, 27 Jan 2014 02:14:27 +0100, Gregor Zattler <telegraph@gmx.net> wrote:
> Hi David,
> * David Bremner <david@tethera.net> [26. Jan. 2014]:
> > Gregor Zattler <telegraph@gmx.net> writes:
> >> I consider this to be a bug.  Instead notmuch should simply
> >> ignore the symlink.
> >>
> > 
> > Since there is a test for specifically this behaviour, I'd have to say
> > it's a design decision you don't agree with, not a bug ;).
> 
> May I ask why this is so?

I have no idea what went on with such a decision, but, from the outside:

1) A dangling symlink should probably be handled in the same way as
   an unreadable file, but would need a separate test because it is
   a separate condition.

2) A dangling symlink should not be a normal condition anywhere, why do
   you have them?

3) I am even more amazed that there should be a dangling symlink in a
   Maildir tree.
> 
> > In any case, if there is just a few broken symlinks, and you want to
> > ignore them, you can add them the ignore= line in .notmuch-config
> 
> Thanks, I deleted some, and ignored others.  Insofar my problem is
> solved. 

Eric
-- 
ms fnd in a lbry

Re: Bug: notmuch new chokes on dangling symlinks and quits

[David Bremner]

Gregor Zattler <telegraph@gmx.net> writes:

> Hi David,
> * David Bremner <david@tethera.net> [26. Jan. 2014]:
>> Gregor Zattler <telegraph@gmx.net> writes:
>>> I consider this to be a bug.  Instead notmuch should simply
>>> ignore the symlink.
>>>
>> 
>> Since there is a test for specifically this behaviour, I'd have to say
>> it's a design decision you don't agree with, not a bug ;).
>
> May I ask why this is so?
>

Purely from memory (I wasn't involved, and didn't dig up the the
discussion):

- a common use case is linking different trees into one notmuch-index
  tree.

- if a subtree disappears (e.g. by a network failure), then the choices
  are stop the index or ignore the missing files.

- in the latter case, all tags from "deleted" messages are lost

So, a simple solution which avoids data loss is to abort the index
process.

A more complicated solution would be possible of course, but nobody
proposed it (or more importantly, did it) yet.

d