Re: [VM] VM writes r/o folders

[Uday Reddy]

John Hein writes:

> I've used local mail folders that the mta writes to for a while now
> (procmail to spool file read by vm).  movemail seems to do a good job
> - I have not experienced corruption/locking problems in this area when
> using vm over the years.

Oh, movemail is a different matter.  It is a separate program and knows how
to inter-operate with MTA's.

Spelling it out, the MTA delivers mail to what we call "spool files".
movemail moves the mail from spool files to VM folders.  Then, we operate on
VM folders.

VM wasn't designed to operate on spool files directly, which is what Julian
seems to be trying.

>  (b) 8.1.1 gets this right.  It doesn't add the 'filed' mark when you
>      file a message from within a r/o folder.  And if you use
>      vm-set-message-attributes, it whines that the folder is r/o.
>      folder).  So it's just a "simple matter" of finding the diff from
>      8.1.1 to 8.2.0 that causes the regression.

I will double check.  But I think the current behaviour is still the same.

> In fact, I think I would prefer that for read-write folders that have
> old attributes.  That is, update the attributes in memory and don't
> mark the folder changed for just folder attribute changes.  Then if
> you don't make any other changes and then do vm-quit or
> vm-quit-no-change, vm just quits the folder without saving the updated
> attributes (and without asking you to save the [internal] folder
> attributes change).  If you do make "real" changes, then vm saves the
> updated attributes along with those changes.

Yes, this behaviour has changed from 8.1.1 to 8.2.0.  The old code was not
marking the buffer as modified.  I will reset it back to the old way.

However, note that Kyle Jones's comment in the code says this:

  ;; tink the message stuff flag so that if
  ;; the user saves we get rid of the old
  ;; short vector.  otherwise we could be
  ;; dealing with these things for all
  ;; eternity.

Personally, I can't see what is wrong with keeping old formats "for all
eternity", but I haven't thought it through fully.  I just think it is safer
to upgrade old formats to new ones in general.

Cheers,
Uday