On Sat, 11 May 2002, Marek Kowal wrote: >> Should the operating system provide system calls for "moving" files also >> across file systems, just because we like to use the command "mv"? >Well, I always thought this argument will fork for me, not for the people >agains MOVE, but apparently it really depends on point of view. Andy, >reading your letter, I have the impression that life would be easier without >moving files, since both necessary atoms - copy and delete - are already >there. So can you really imagine working with today's filesystems without >REAL move system call? It would be such a waste of resources! What you >described is exactly what I want - operating system provides you with move
I guess you know, if a "mv" operation across file systems is terminated, then there is junk in the destination folder. There are numerous ways to work around this bieffect (copy to tmp, sync, rename), but considering all the numerous ways to implement "whatever lies beneith the VFS layer", the job is left to the application and not the OS. In any case, for moving of a message to be consistent, there will at certain state have to be a copy in both the source and the destination folder/file. I'm not considering high level Corba backends now, I'm thinking about over 90% (guess) of email depositories, which are unix spools (single file per folder) or similar, Maildirs and so on. "copy" (or read and write), "link", "rename" and "delete" are considered to be atoms in operating system design. "move" is an aggregate command, and is therefore left as a job for applications such as "mv". Should the IMAP protocol be different? >system call, and where it is not possible, it will fake it by >copying/deleting the file. That's exactly what I want from IMAP. There are >two possible solutions: >1. We put MOVE command directly in the RFC. Then all server programmers are >supposed to implement it, and for the mail stores, which do not allow it, >fake it by implementing copying and deleting. My point here, is that a "move" operation implies recovery and consistency. The safest way to do this is to copy, sync, and remove the original. For all depositories where one message is /not/ one file, this is how it will be done anyway. Please consider standard depositories, and not just your own special-case not-actually-a-message-depository. Consider how MOVE can be done atomically in a Maildir, an mbox, or a unix spool, for instance. My IMAP own not-actually-compliant server works as a proxy for multiple XMIT-capable POP accounts, aliased as folders. An atomic MOVE operation for this design would be a complete nightmare! >implementations, which COPY/STORE/UID EXPUNGE does not allow. I want to >move, not copy, in short ;-) Then I'm back to my earlier question: For who's benefit do you mean to implement MOVE? To the user, the programmer or for some sake of efficiency? Please for once, tell us for what purpose you wish to have MOVE defined in the RFC. Other than "I want to...". >In the end, it all comes to important reference implementation. Preferably >in some widely used server, be it UW IMAP or Cyrus IMAP. Otherwise the whole >stuff is wasted, for nobody will implement "yet another server extension" in >clients unless 50% of servers do not support it. That's why I'm so >interested in pushing this case forward through this forum. If Mark agrees >on that and support would go to c-client, people would start using it >immediately. If not, then we've been just wasting bandwidth of internet >links with those posts. So your motives for posting to this list are clear, but still all do not agree. If MOVE goes through, then many people might have to re-think their MUA design (if it's modelled after IMAP principles). Perhaps what you're looking for is not IMAP, but rather a proprietary system for your own backend. Andy >Cheers, >Marek. > > -- Andreas Aardal Hanssen
