[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] attach
Re: [Nmh-workers] attach
Sat, 15 Sep 2012 12:10:04 -0500
> 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.
> >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
If you're talking about a new, standalone attach, that sounds
reasonable. But I think that we should leave the checks in,
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
> If you accept that requirement then, given the above about send, I
> attach should reject with, an error message, any:
> Unreadable files (including directories)
> Dangling symbolic links
> Symbolic links to unreadable files (including unreadable
> 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
> 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
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.
- Re: [Nmh-workers] attach,
David Levine <=