On Tuesday 10 April 2012 20:05:53 Daniel Baumann wrote: > On 04/10/2012 03:26 PM, anonym wrote: > > Snapshots can no longer be partitions; only snapshot files are > > supported. > > absolutely.
I agree too. The only drawback of this is to cancel the original use case that had me develop snapshot in the first place. In a school environment, have some 'work' files readable without too much problems also on windows in a fat32 partition on the usb key. The snapshot was required to not stress to much flash memory and fat32 was a requirement to play nice with that "home" os. A part this, no problem with that. I'm not interested a lot in this use case, but beware that it could be used in similar environments so before cutting a feature to achieve string beauty think twice please. > > If this is acceptable I propose that snapshots are activated by a > > live-persistence.conf option called > > "snapshot=PATH_TO_SNAPSHOT_FILE" (extension is optional). A > > > complete example line is: > ack. > > unrelated to that: imho, the term 'snapshot' is a misnomer. > > i understand and expect something different under a snapshot in the > filesystem context. for me, a snapshot consists not of the diff but of > the entire data of a filesystem. like a dump made at a particular > point in time. The name came from the way it is used time-wise, not content-wise. Because you must "sync" it (automatically at reboot/halt or manually with live-snapshot). > while we are at it and this is a good time to name things properly, do > you have a better, more suitable name in mind we could use instead of > 'snapshot' to designate an 'overlay packed into a file'? > > We could probably drop support for /etc/live-persistence.binds What replaces that thing nowadays? It was handy to save some unwanted data to be saved/restored. -- ESC:wq -- To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201204102015.37026.marco.amad...@gmail.com
