Re: [Nmh-workers] attach

[David Levine]

Norm wrote:

> David Levine <address@hidden> writes:
> >Norm wrote:
> >
> >> I don't know that whatnow's attach ever gave me a blank
> >> Nmh-Attachment header.  What you are probably referring to
> >> was my request that send silently remove any such
> >> headers. I asked for that so that users could put them in
> >> their templates to be filled in, or left blank at
> >> composition time.
> >
> >I just committed the fix for that, but only in send(1).
> >post(8) is coming.
> >
> >Also:
> >
> >Added check in send(1) of attach (default Nmh-Attachment)
> >headers to ensure that only plain files are attached.
> >Otherwise, it is a fatal error.  Note that whatnow's
> >attach will continue to allow attachment of directories
> >because it expands those out to their contents.  It
> >doesn't check what the contents are, though.  That's why
> >we needed to add this check.
> >
> >It does the right thing with symlinks, as long as they
> >dereference to plain files.
>
> It seems to me that, ideally, attach should never attach anything
> that send would reject as an error. Is this too unreasonable a
> requirement?

If you're talking about a new, standalone attach, that sounds
reasonable.  But I think that we should leave the checks in,
anyway.

I added this check to post:

    Filter out all Nmh-* headers in post(8).  Do that
    silently for empty ones (no header body), and warn about
    non-empty ones.

> If you accept that requirement then, given the above about send, I
> suggest
> that:
>
>   attach should reject with, an error message, any:
>
>      Unreadable files (including directories)
>
>      Dangling symbolic links
>
>      Symbolic links to unreadable files (including unreadable
> directories)
>
>      Directories or symbolic links to directories, unless the -r option
> is given

Note that the current "attach -r" is an undocumented relic of the
implementation, because whatnow passes the -r to ls.  Maybe it
shouldn't even be allowed.  The whatnow documentation specifically
says "attach files".

> Even though attach should check symbolic links, it should attach a
> symbolic link to an ordinary file as the link itself. (This would
> allow the link to have a different suffix then the file linked
> to). That's what it does now.

Are you sure about that?  When I attach a symbolic link
to a plain file, it attaches the file, not the link.

I think that's much more useful than trying to send a MIME
symlink.  And I'm not sure how portable that would be.
inode/symlink is out there but IANA doesn't list an inode
content type.

> If the -r option is given then attach should recursively
> attach all files (including files whose names begin with
> '.' ?) in any directories encountered.
>
> Since a simple error, could inadvertently generate hundred of
> attachments, maybe attach should return with the number of files
> attached, when the -r option is given, or perhaps always, for
> consistency.

I'm not sure what we could do with that return value.  And
if you're talking about a large value, I likely wouldn't
notice the difference between two large values.

And if there's an error, I'd like it to just fail so I
could fix it.

> Maybe requiring attach to not make send unhappy is overkill, and is
> not worth the extra trouble?

I don't think it's worth the (my) trouble to try and add/
subtract these to/from whatnow's attach.

David