Just a sample of the Echomail archive
Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.
|    ARTWARE    |    TimEd, NetMgr, WIMM Support Conference    |    350 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 104 of 350    |
|    andrew clarke to All    |
|    timEd message base locking (or lack ther    |
|    25 Oct 12 04:38:04    |
   
   > Can't open message (594)!   
   > MSGAPI: MERR_NOENT: File/message does not exist   
      
   This is very old news, but I don't think I ever documented it. It's what   
   happens in the UNIX version of timEd when you start writing a message destined   
   for a Squish message base but in the background a message is imported into the   
   same echomail area by another program, eg. HPT.   
      
   I don't think you actually lose any messages but the index seems to get   
   corrupted somehow. The way I fix it is to run sqconver (from MSG   
   PI/SMAPI/XMSGAPI) over the broken msgbase, then replace the original msgbase   
   with the newly created one. Obviously you wouldn't want to do this while HPT   
   is trying to toss messages into it, though.   
      
   I don't think this happens in the OS/2 version because of file locking,   
   meaning HPT (or Squish) can't write to the .SQD file while timEd has it open.   
   Then again, back when I used OS/2 I don't ever recall having locking   
   violations, so I'm not sure. Maybe Squish just waited until the msgbase became   
   writable.   
      
   In UNIX, file locking works quite differently than in DOS, Windows & OS/2.   
   From Wikipedia:   
      
   "Although some types of locks can be configured to be mandatory, file locks   
   under Unix are by default advisory."   
      
   In simplistic terms this means HPT & timEd need to cooperate with each other   
   with regards to not clobbering each other's files, but they're clearly not   
   doing that.   
      
   The timEd code is broken though. It shouldn't be doing this (pseudocode):   
      
   ma = MsgOpenArea("artware")   
   mh = MsgOpenMsg(ma)   
   txt = GetTextFromUser()   
   MsgWriteMsg(mh, txt)   
   MsgCloseMsg(mh)   
   MsgCloseArea(ma)   
      
   Instead it should do this:   
      
   txt = GetTextFromUser()   
   ma = MsgOpenArea("artware")   
   mh = MsgOpenMsg(ma)   
   MsgWriteMsg(mh, txt)   
   MsgCloseMsg(mh)   
   MsgCloseArea(ma)   
      
   I have no idea if the same bug (or a different bug...) occurs when writing to   
   *.MSG format bases.   
      
   The main reason I'd not bothered to attempt to fix it is because it's (from   
   what I can tell) a fundamental design problem with timEd. Also, it only   
   affects me very occasionally on account of me only posting to very low-volume   
   echomail areas.   
      
   It's also a design fault with Scott Dudley's design of the MSGAPI. A   
   well-written API shouldn't allow data corruption of the very thing it's   
   allowing you to access. Of course it's easy to say that in hindsight all these   
   years later.   
      
   I think from now on I'll be using GoldED or Msged just to avoid needing to run   
   sqconver again. I'm pretty sure both of those write to Squish messagebases the   
   correct way (see above psuedocode).   
      
   In an ideal world I'd write my own very basic message editor in Python and   
   bypass the MSGAPI altogether but doing that is pretty low on my list of Things   
   To Do(tm). :-)   
      
   Regards   
   Andrew   
      
   --- timEd/FreeBSD 1.11.b8   
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca