In operational system VMS of computers DEC VAX there was one delightful opportunity, - OS kept all versions of files. Those are, when you wrote down the same file in the same place of file system the operation system did not overwrite an old file, and added to a name of a new file number of its version. The name of a file looked so:
File_name.file_extention:file_version_number
If the same opportunity could be realized in Haiku, it would be full DELIGHT! For clearing file system from old versions of files the command purge has been stipulated. Has been stipulated also system purge. In Haiku it would be possible to realize this idea by means of attributes and essentially to develop. For example, in adjustments it is possible to provide following options:
Full switching-off of storage of versions of files.
To specify depth of preservation of versions of files. We shall tell, to store no more than three versions. At preservation of the new version, most old version automatically to delete.
Do not create versions for files, which size more the than set size.
Do not create versions for files of the certain type.
Do not create versions for the files few differing on time of updating.
Purge files it is more or less the than set size, an interval on time of creation, etc., etc.
Great idea. In fact, I was about to start a post about this. I’ve been using dropbox for a little bit and really think I might be able to figure out how to implement this. Though I’m not familiar with Haiku ins and outs. If it can’t work for a reason, discuss why please (helps me learn :D)
Assumptions:
- There is a daemon that watched certain folders, files.
- No file larger than a user configurable size is backed up
Implementation:
- When a file is opened for write in a watched folder, make a copy of it in a
hidden folder 'diffs' in the file's own folder
- When the file handle is closed, run 'diff' (if there's a port) on both the
backed up file and the newly updated file. Save the diff in the 'diffs'
folder as 'filename.revision(number).action_performed'
- Actions performed could be 'rename', 'updated', 'restored'
- If there is a way to get the inode information, we should use that instead
of 'filename' to deal with renaming of files and the rare possibility of
creating a filename that is too long
- When the user right clicks a watched file, there should be a context menu
that uses queries in the diff folder to show the last ten files, the option
to purge all but the last three revisions, view all, and the option
to unwatch the file
- Clicking on one of the files in the context menu will return the file back
to its previous state and create a new restore point for that file
- User configuration window would include some of Sergey's ideas:
- Enable the daemon
- Filesize cutoff (ex: don't backup files bigger than 10MB)
- Watch certain files/folders (add/remove) (also use a tracker context menu)
- Keep only X revisions
- Keep X megabytes worth of revisions for each file
- Purge all revisions?
Anyone think it’s worth thinking about more deeply? I’d love to implement this as a GSoC project
like Shadowcopies in windoze-world, maybe?
maybe also add a default attribute field to all files - importance (to user)? so if i set it to 5 stars (?) and it’s very important (to me, the user), then it’s versioning goes further back then other files. ‘shadowcopies’ could be kept maybe in the unused space of the disk and cleared, older first, and taking ‘stars’ into account. the space is that way dynamically allocated and user always knows that the trade-off of having too much files is shorter file-history. maybe if say less then 10% of free space remains, system would give user a warning about the shortened versioning history etc… shadowcopies could be kept as attributes attached to files or attributes as pointers to files that are marked ‘deleted’ (like in dos) but actually still there, u overwrite the 'shadowcopy and just remove the pointer (attribute)… sorry, i’m more of a dreamer then programmer, but maybe somebody picks something up from this
