>> 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
As it was said before, there is simply no MOVE command in IMAP, even no MOVE to Trash. A client always has to do a copy and delete to perform move, and at the moment of the copy, it counts on quota. > 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