Mercury wouldn't be able to do what you ask, without having really advanced deterministic behavior about what a client could be doing as next command.

 If a mail server was to store an e-mail with attachment of 5MB without consuming the server RAM, it would need an overall cache engine to query first and disk data secondly. In the background Windows does this on local files, but serverwide, meaning over network lans, and other OSs, client side caching is dangerous. This is the reason why many have large issues with file based databases, and the bad solution called opportunistic locking. 

Hi,

we see some strange things here, wanted to clarify, if I interpret it right:

- Mercury32 in NDS mode (i.e. all Mailbox files are on a NetWare Server)

- Imap client reads e-mail with 5MB attachment (or any other large size). It reads it in 16KB chunks. Example from Session Log:

310 UID fetch 28 (UID RFC822.SIZE BODY.PEEK[]<4980736.16384>)<cr><lf>

- For every time, the imap client reads a 16KB chunk, Mercury seems to read in the _whole_ file from the NetWare server. This can be seen with various monitoring tools (throuput on the wire, file open/close monitoring on the NetWare server).

Needless to say, if the attachment is big, this causes a lot of needless traffic between the Windows server with Mercury and the NetWare server.

We noticed this with Thunderbird Junk Filter (normal Mail download seems not to be affected) and MacOSX Mail.

Has anybody else noticed this? Is this the normal behavior, or am I misinterpreting things here?

Greetings

Markus