What exactly would dictate a move?
Even on many OS's move copies the file, make sure that it is a good
copy, and then deletes the original. MOVE still wouldn't handle this
case because there still needs to be 2 copies at a given point in time
to handle fault tolerance.
Just a thought,
B
Gregg Berkholtz wrote:
On Fri, Jul 01, 2005 at 02:00:03PM -0500, John Madden wrote:
Because IMAP doesn't provide a "move" operation for messages. Your
client is probably first doing an append of the message to the
destination folder (which is what's putting it over quota) then storing
the delete flag of the original message and expunging.
I'm sure we've all had problems with this.
Is it wise to modify these clients to instead FETCH, delete/expunge, then STORE?
John
Correct me if I'm wrong, but wouldn't FETCH, delete/expunge, STORE pose
performance issues for users attempting to move large messages and/or
folders, while using a client behind a less than ideal connection (ie:
modem, T1, broadband, etc)?
With the long-time shift towards the concept of "Trash" and "Recycle
Bin". It sounds like the IMAP spec needs a MOVE - if not just for the
ability to MOVE very large messages around, or to move messages into
the trash when a mailbox is near its quota.
Couldn't such a spec change be implemented as an RFC "SHOULD", therefore
allowing servers and clients the option to implement it.
Gregg
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--
Robert Scussel
1024D/BAF70959/0036 B19E 86CE 181D 0912 5FCC 92D8 1EA1 BAF7 0959
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
