Re: (provide 'nnmaildir)

[prj@po.cwru.edu (Paul Jarc)]

<URL:http://multivac.cwru.edu/prj/nnmaildir.el>
feature: -wipe-on-delete
bugfix: -request-accept-article correctly finds end of a header
bugfix: Xrefs track changes in group names
bugfix: gnus-declare-backend is called

If you want messages and .nnmaildir files to be wiped on disk before being
deleted (this applies only to files with a single hard link), use a
select method like:
'(nnmaildir "whatever" (nnmaildir-wipe-on-delete t) ...)

There is a change in the .nnmaildir file format - Xrefs are generated
on the fly, and not stored in .nnmaildir.  But it seems Gnus tolerates
the extra garbage at the end of a NOV line, so you can just wait for
all your old .nnmaildir NOV lines to disappear with expiration.  You
can also fix your old .nnmaildir files with:
M-x replace-regexp RET C-q TAB Xref:[^ C-q TAB C-q C-j ]* RET RET
Or, if you don't care about losing marks, the usual: kill your
nnmaildir groups, exit Gnus, delete your .nnmaildir files, start Gnus
again and resubscribe.

Does anyone have a better way to wipe a file than this?
    (insert (format (concat "%" (number-to-string nchars) "s") ""))
    (write-region (point-min) (point-max) file)
After implementing this, I realized it might not do any good,
depending on how write-region works.  If it opens the file with
O_TRUNC, then I might be writing to different disk blocks than were
being used for this file's data before write-region opened it.  If
instead the file is opened (without O_TRUNC), written, and then
ftruncate'd, all is well.  Does anyone know which it is?

I still haven't figured out why -request-accept-article isn't seeing
that nnmaildir-filename is bound.  I've tried making it buffer-local
instead of bound by let; no dice.  It seems that -request-move-article
isn't even being called: I put in some message calls for debugging,
and nothing showed up in *Messages*.

What's the difference between gnus-summary-copy-article and
-crosspost-article?  Is the backend required to update a message's
Xref in either case?


paul