Re: folders which are numerical names

I'm willing to bet if I look back in the prior 3 decades I'll find myself
asking the same question and the infrequency of it bugging me, is a strong
indication of how (un)important it is.

maybe I'd move my marker and ask if it could become a "soft" error on scan:

% ls -F | sort -n | tail -5;
586
587
588/
589
590
% scan +sent
...
   584  2024/06/17 To:Leo Li
   585  2024/06/18 To:APNIC Office
   586  2024/06/18 To:Dan Fidler
   587  2024/06/18 To:Joao Damas
scan: unable to read: Is a directory
scan: scan() botch (-3)
%

i would think the file/dir name is available at point of fail so we could
get a botch message identifying the culprit and .. move on?

Not going to die on the hill. Things are working fine otherwise.

-G

On Tue, Jun 25, 2024 at 12:07 PM Ken Hornstein <[email protected]> wrote:

> >if your folder is a primary directly under $MAILPATH/ it works fine, as a
> >pure numeric
> >
> >so folder +2021 is fine -and I do this for archives by year.
> >
> >if your folder is sub-folder under another folder like +sent/2021 it only
> >kind-of works. Any function which performs scan functions looks to pure
> >numeric objects as files, and barfs on the directory. So I work around it
> >by having archives like sent/y2021 and it works fine.
>
> The exact case is that there isn't a problem as long as something that
> is a folder doesn't contain a non-file who's name consists of all decimal
> digits.  So in theory 'scan +$MAILPATH' probably won't work so well (but
> maybe that's not that useful in practice).
>
> >the other path out here is to do folder +2021/sent and subfolder sent
> >inside the archive year which works fine.
> >
> >I just wondered if a stat() on the object to skip (sub)folders in contexts
> >which demand files would work? Might be a pain to implement without
> >unwanted side-effects.
>
> This comes up occasionaly, most recently here:
>
> https://lists.nongnu.org/archive/html/nmh-workers/2023-03/msg00000.html
>
> Unfortunately, there are no good answers.  stat()ing every possible
> message would be very expensive.  dirent->d_type is not always reliable
> (and it's not easy to figure out when it will be reliable).  The consensus
> in the past has been "don't do that".  I am open to suggestions of course.
>
> --Ken
>