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 >
