JCooney.NET

# re: Raymond Chen says I am insane 1/8/2004 10:01 AM Shannon J Hager

coincidentally , in a semi-related note, I found out accidentally yesterday that ctrl+Z will undo a cut & paste on files. It blew my mind, I never realized that was possible.
If you copy and paste a file, then ctrl+Z, Windows will deleted the pasted file after you confirm the decision.

# re: Raymond Chen says I am insane 1/8/2004 12:03 PM 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.

# re: Raymond Chen says I am insane 1/8/2004 3: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"?

# re: Raymond Chen says I am insane 1/9/2004 4:31 AM 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.

# re: Raymond Chen says I am insane 1/12/2005 2:01 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).