Subject: Re: export whole folder?

From: Don Sugarman <[email-masked]>
Date: Fri, 2 Jun 1995 23:10:35 -0400 (EDT)

On Fri, 2 Jun 1995, Mark Crispin wrote:
> Here's the full story:

<MAJOR SNIP>
Wow!  Thanks for the explanation.
> 
> So, that's the issue.  Input from the external user community on this is
> solicited.  Specifically:
> 	Why do you want to use mbox format on DOS, given that Pine has a
> 	 read/write format that it can handle much better/faster/safer?
> 	How do you anticipate using a read/write mbox driver?
> The answers to these questions affect *how* a read/write mbox driver would
> be implemented, given all the tradeoffs that have to be made.
> 

I'm going to go out on a limb here as say that most users are looking for 
a functional capability of viewing their INBOXes off line and operating 
on the INBOXes as if attached to their UNIX server.  They probably don't 
care what format they are in.

I'll bet a neat feature would be to queue up message responses (replies, 
forwards, bounces) off-line and have them processed upon reconnecting to 
the UNIX server.  CIS users wanted/got this feature from a number of 
products, including TAPCIS.

That's my .02 dollars.

Don Sugarman
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Fri, 2 Jun 1995 19:32:35 -0700

On Fri, 2 Jun 1995, Ben T. Feese wrote:
> Actually the PC Pine documentation was where I originally found the
> statement that Unix pine folders would only be available to PC pine in
> "read only" format.  I do not know why this is so, but it is *not* due to
> the DOS "readonly" attribute being set.
>
> What I really need to know is what the difference is between the PC and
> the Unix folder formats that creates this problem.

There *WILL* be a read/write mbox driver on DOS in the future.  The
question is what form this will take.

Here's the full story:

The present mbox driver for DOS, bezrkdos, is a read-only driver.  This is
because of the nature of mbox format folders.  In the mbox format, it may
be necessary to rewrite a message with a "Status:" and "X-Status:" header
line that is not present in the message.  This, in turn means that you can
not overwrite the folder in place without maintaining a separate copy of
the subsequent messages.  You can't just read the subsequent messages
while you're updating the previous messages, because a previous message
can grow and overwrite a subsequent message.

To work around this problem, the UNIX mbox driver in Pine keeps all
messages in memory.  This is simultaneously boon and bane; it's a boon
because searches are all in memory and thus *very* fast, bane because it
makes some Pine memory images huge.  Of course, there's no way you can do
this on DOS with a 640K limit!

Another way is to write to a separate copy of the file.  Unfortunately,
there is a requirement on many UNIX systems that the inode of the folder
be preserved.  So, you can't just write to a new copy and then rename the
new copy to the old name.  The upshot is that you would have to copy to
the separate file, then copy back.

A further problem with writing to a separate file is that a lot of our
in-house users (the community that funds Pine development!) are at the
limit of their disk quotas and do not have the free space available to
permit a second temporary copy of their mail folders.

What does this have to do with DOS?  Well, the question becomes *why* do
you want a folder in mbox format on DOS.  Tenex format is used on DOS, and
PC Pine handles tenex format much better than it could ever handle mbox
format.

There are two answers to this "why".

One is that people just want to FTP their mbox format files to the PC and
work with them on the PC.  There's no need to worry about the UNIX inode
or locking restrictions, and most PC users have plenty of disk space.
This is true, and it wouldn't be too hard to make a read-write mbox driver
on DOS for these guys.  But on the other hand, it's even easier to use PC
Pine to covert the mbox folders to tenex format on the PC, or use PC Pine
to copy them from the UNIX system into tenex format using IMAP.

The other one is that people who have NFS mounts from UNIX to their PC
want to manipulate their UNIX folders from the PC over NFS (instead of
over IMAP).  This present several problems; all of the UNIX problems plus
all of the DOS problems.  How do we do the UNIX locks on DOS?  How do we
make sure the same inode is preserved?  How do we avoid disk quota
problems?

Unfortunately, the NFS answer is the compelling reason for mbox format
support in PC Pine at our site.  We haven't figured out how to do this
read/write while still being safe yet.  We do *not* want to "just do it"
and then have thousands of bug reports about crashed mail folders.  We get
enough of these when we're careful!  ;-)

-- Mark --

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.

---

From: "Ben T. Feese" <[email-masked]>
Date: Fri, 2 Jun 1995 10:48:33 -0400 (EDT)

Thanks, Don

On Fri, 2 Jun 1995, Don Sugarman wrote:

: Ben,
: Your read-only attribute on the file when it gets to your PC *could* be 
: based on the ftp settings - e.g., 255.255.254.000 or whatever.  (I don't 
: have enough experience to tell you what to do, but I have experienced the 
: problem, myself.)
 
: If you can't get ftp to put it onto your PC in read/write mode, can't you 
: just give it write permissions with the DOS ATTRIB command?  (I use 
: Qfiler for file management, so I'm not exactly sure about the DOS command 
: syntax.)
: 
: Anyway, just some ideas to try.
: Good luck,
: Don Sugarman
: [email-masked]
: