Kevin Dente paints a picture of the far off future where windows explorer has an option to “skip problematic file and continue copying other files” if it encounters a problem during a copy operation. In the comments I suggest it would be nice if in this brave new world explorer also had an option to “roll back” operations (like copy or delete) that failed because of a problematic file. Raymond Chen thinks the “rollback” idea is insane . Now I know that an option like this would require the file system to support it (and thus would not be trivial to implement like the “continue copying“ option that Kevin suggests) but (insane or not) I think the rollback idea is a good one.
Comments
Clayton Firth
Windows already has this feature implemented to a certain degree with “System Restore”. Granted this functionality only has control over system files currently but it’s not hard to imagine this working over a complete file system at some point in the future, particularly as storage becomes cheaper and cheaper.
8/01/2004 12:03:00 PM
Raymond Chen
Consider this scenario: A folder on your hard drive has two files, X and Y, each say 32K. On your floppy disk is a folder that has two files, also called X and Y, each say 32K also. But the X and Y on the hard drive are different from the X and Y on the floppy disk. what’s more: Your floppy disk has 0 bytes free.
How do you implement rollback in this situation? Or should the copy just fail with "There is insufficient disk space to complete this operation"?
How do you implement rollback in this situation? Or should the copy just fail with "There is insufficient disk space to complete this operation"?
8/01/2004 3:00:00 PM
JosephCooney
Raymond - you’re certainly not the first person to call one of my ideas insane and you probably won’t be the last. Let me try and explain….
I use a program called subversion for version control (at home). It has a windows shell extension so I can click on a file in the shell and commit changes made to it back to the master repository (if it is under version control). This got me thinking "why doesn’t windows do this for me already?". Now I know in the "back end" subversion sticks my updated file in a relational database. What if the windows "file system" that I interact with thru explorer, the command prompt etc was just a "view" into file data stored in a relational database? What if I could right-click on a folder in explorer and check a box saying "remember changes to items in this folder" or click on a file and do the same? What if I could right-click on a file and select "Show version history" from a context menu? I think if file copy/delete operations were all done against such a transacted data store then rolling back a failed copy or delete would not be too hard.
I hoped when I first heard about the new WinFs in longhorn that this might be the sort of file system we were moving towards (but from what I have seen it is more about meta-data than anything else - I could be wrong about that since I haven’t had much time to look into WinFs).
In short I think I might be asking for the entire file system to (optionally) be stored in a relational database. Would this be hard? Maybe. Bad for performance? Sure. Does it improve the user experience? Well, it might mean that users might never lose their data (if they knew about it).
Remember they laughed at Einstein, but they also laughed at bozo the clown. Now if you’ll excuse me I need to go and get my funny hat, unicycle and juggling balls.
I use a program called subversion for version control (at home). It has a windows shell extension so I can click on a file in the shell and commit changes made to it back to the master repository (if it is under version control). This got me thinking "why doesn’t windows do this for me already?". Now I know in the "back end" subversion sticks my updated file in a relational database. What if the windows "file system" that I interact with thru explorer, the command prompt etc was just a "view" into file data stored in a relational database? What if I could right-click on a folder in explorer and check a box saying "remember changes to items in this folder" or click on a file and do the same? What if I could right-click on a file and select "Show version history" from a context menu? I think if file copy/delete operations were all done against such a transacted data store then rolling back a failed copy or delete would not be too hard.
I hoped when I first heard about the new WinFs in longhorn that this might be the sort of file system we were moving towards (but from what I have seen it is more about meta-data than anything else - I could be wrong about that since I haven’t had much time to look into WinFs).
In short I think I might be asking for the entire file system to (optionally) be stored in a relational database. Would this be hard? Maybe. Bad for performance? Sure. Does it improve the user experience? Well, it might mean that users might never lose their data (if they knew about it).
Remember they laughed at Einstein, but they also laughed at bozo the clown. Now if you’ll excuse me I need to go and get my funny hat, unicycle and juggling balls.
9/01/2004 4:31:00 AM
David Bennett
Raymond Chen is mistaken.
This is a great idea! How do I know? Because it’s an idea I had myself some time back, and have already thought through in some detail.
Point: don’t even think about implementation. There is absolutely no need for the file system to be stored in a relational database. Subversion uses it because the Berkeley db gave them rollback for nothing.
Point: this is not simply for undo/redo. Both undo and redo are logged and versioned.
Point: the real strength is that copy is (nearly) free, and amounts to a branch. You can create projects out of branched/copied files as you need them.
Point: I would not expect to use a versioned file system on a diskette, CD or network (for now), and running out of disk space is a disaster (as it is now for Windows).
This is a great idea! How do I know? Because it’s an idea I had myself some time back, and have already thought through in some detail.
Point: don’t even think about implementation. There is absolutely no need for the file system to be stored in a relational database. Subversion uses it because the Berkeley db gave them rollback for nothing.
Point: this is not simply for undo/redo. Both undo and redo are logged and versioned.
Point: the real strength is that copy is (nearly) free, and amounts to a branch. You can create projects out of branched/copied files as you need them.
Point: I would not expect to use a versioned file system on a diskette, CD or network (for now), and running out of disk space is a disaster (as it is now for Windows).
12/01/2005 2:01:00 AM
If you copy and paste a file, then ctrl+Z, Windows will deleted the pasted file after you confirm the decision.