On Wed, Jul 06, 2005 at 12:48:30PM -0400, Robert Scussel wrote: > 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. > > > 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 >
I dont see that behavior on my Linux-based systems. When I issue a "mv" for many thousands of files, or for very large files, the change occurs immediately. At least in the sense that a "sync" shows no pending operations, even after issuing a command such as: mv /home/user/2GBfile.txt /tmp/2GBfile.txt; sync Of course that assumes the mv source/destination are on the same partition. Though this is getting pretty deep into the OS level of things, shouldn't the IMAP daemon just issue the "mv" call, and depend on the OS to return a failure if that command could not be completed? I don't see how this differs from a situation where a user is far below their quota, but copies to a destination partition which fills up before all data is written. Though I've never let my partitions get so low on free space. Does anyone know how Cyrus behaves if a copy destination prematurely runs out of available disk space? 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
