RE: Request for feedback: Filesystem API

> This seems terribly complicated. It's unclear what problems it is
> trying to solve.
>
> If the problem is simply to enable recovery during multi-file
> operations the simpler fix is to define that for non-atomic move()
> operations across filesystem backends (if we end up keeping support
> for those) work by first copying all files, and then deleting all
> source files.
>
> That way, if the copying fails somewhere it is easy to recover by
> simply deleting all the destination root. If the deleting failed
> somewhere it is easy to recover by deleting the source root.
>
> Recovering from a failed copy is always easy by simply deleting the
> destination root.

This is totally overlooking the real issues directory copies face in real life.

When you copy or move a folder, you get conflicts. Any responsible API for dealing with non-atomic file operations has to offer at least a way to resolve conflicts. And conflicts are not the worst you can get. What about someone trying to delete a file that is currently in use?



By the way, my proposal is *not* complicated. The WebIDL surely looks like, but it's a lie.



Firstly, the simple "let's just do it and ignore all errors" approach is still extremely simple:


   // let's copy
   myFirstFolder.initMove(mySecondFolder).start().then(...)
   
   // any conflict is resolved as don't copy/don't delete
   // any copy faillure results in a don't delete
   // any delete faillure results in no delete
   // 
   // this is a safe default, no data can possibly be lost


And, very importantly, this code starts the same way as the more fine-tuned approach (ie: the API do 
not favor lazy coding by having an easy-to-use buggy approach (copy), 
and a completely different approach for good code with proper error 
handling (enumerateDeep, and just do it all yourself)).



Secondly, the most complex thing you may imagine would look like that:


   var dialog = new FileOperationDialog(); // custom user-code
   var move = myFirstFolder.initMove(mySecondFolder);
   
   move.oncopyerror = function(e) {
      if(e.error.type=="conflict") {
         
         // let the user choose how to solve the conflict
         e.error.registerHandler(
            dialog.addCopyConflict(e)
         )
         
      } else {
         
         // let the user retry/ignore/abort
         e.error.registerHandler(
            dialog.addCopyFaillure(e)
         )
         
      }
   }

   move.ondeleteerror = function(e) {
       
       // let the user retry/ignore/abort
       e.error.registerHandler(dialog.addDeleteFaillure(e))
       
   }
   
   move.onerror = function(e) {
      
      // rollback if any error was not handled (abort) by the user, at the end 
      e.successes.inReverseOrder().forEach(function rollback() { 
          ... 
      })
      
   }

   move.start().then(...)


Your proposal simply does not provide a sufficient amount of primitive to handle this *basic* deep copy scenario right. I dare you proposing a code that does allow something even close to that. 



And, seriously, handling conflicts can be done in so many ways. For example, when doing directory syncing (imagine a cloud-synced and a local "folder"), you may simply resolve all conflicts by modification date. This can be done very easily using this proposal. What about yours?

This also enables fine-grained progress dialogs that display the current file being worked on, etc...



If FileSystem-related operations were really that simple, they would not be worth multiple blog posts on the Windows 8 Engineering blog many years after they originally were introduced in Windows [1][2] nor would people use specific syncing software like FileZilla (that allows you to resolve conflicts to "do not copy in case of conflicts if some metadata matches) over an FTP connection to save bandwidth, nor would the "cp" command on linux have dozens of available flags [3].
 



[1] http://blogs.msdn.com/b/b8/archive/2011/08/23/improving-our-file-management-basics-copy-move-rename-and-delete.aspx
[2] http://blogs.msdn.com/b/b8/archive/2011/08/26/designing-the-windows-8-file-name-collision-experience.aspx
[3] http://linux.die.net/man/1/cp

Received on Monday, 19 August 2013 17:56:08 UTC