[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] The invisible mail folder

From: Joel Reicher
Subject: Re: [Nmh-workers] The invisible mail folder
Date: Tue, 27 Feb 2007 12:13:45 +1100

> > > This is even a more general bug: Try "refile +inbox/11111; scan +inbox"
> > > for example. I think subfolders are a feature, numeric folder names
> > > probably are not. (Allowing them would rise quite some questions
> > > about the semantics of sequences and so on ...)
> > 
> > The problem is not in the sequence, but in what scan (et al.) does
> > when it encounters a numeric directory entry that it can't read. At
> > the moment it dies a horrible death and can't scan past that point.
> I still think that numeric folder names rise questions: Consider the
> above example. cur = inbox/11100. What should "refile next:22 +foo" do?
> Move the numeric folder? Leave a copy with the name ",11111" around?
> (Note that you can't have hardlinks to directories on the filesystems
> I know.)

I think it should do the same thing I hope to make scan do, i.e.
give a warning something like "Can't handle message <number> because
<reason>, skipping..."

In the case of a sequence like next:22, I think it makes sense for
the skipped problematic "message" still to count in the 22, since "skipped"
is not the same as "not there".

So even though refile is able, from a code point of view, to move the
directory, I don't think it should. Rather, I think it should be consistent
with scan's behaviour.

> If we decide, that nmh tools should explicitely ignore any non-regular
> files, could this be done by a change in one central place? As far as
> I know the source I doubt it.

Whenever I get time I refactor the nmh code to gather common stuff into
one place. In fact, it was probably this kind of change that introduced
the "+.." problem.

I'll *try* to refactor as part of these modifications. Wherever the
refactor can be done easily I'll do it first and then introduce the
change. In other cases I might decide it's easier not to refactor yet.

> > I think it would make much more sense for the nmh commands to be
> > fault tolerant rather than restrict what can be done with folder-creating
> > commands, since there are so many other ways for nasty directory entries
> > to be created (i.e. by non-nmh commands).
> Perhaps there is a misunderstanding here:
> No, I don't want to restrict the folder-creating commands in any way.
> When I say that numeric folder names should not be a feature, I only
> mean that it shouldn't be encouraged and when they break something
> somewhere then nobody should be surprised.

Does the diagnostic I describe above satisfy you?


        - Joel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]