On Sat, 2003-04-12 at 13:22, Joerg Schilling wrote: > >> This is why I don't trust mkisofs as backup tool - just because I never > >> do complete checks with the created images. > > >Well, with my patch you can do such a check, even after an > >incremental backup. > > >From reading you other stuff below, it looks like you did not understand > what an incremental backup _really_ is. Mkisofs does not allow you to do > true incremental backups, you may only archive some new files but one of the > main features of an incremental backup - deleting outdated files - is not > (yet) possible. Or does your patch solve this problem?
Yes, it does. It allows you to repeatedly store the same set of files or directories so that they appear in different directories, Each of these directories is a snapshot of the harddisk at the time when the backedup was made. If my email or the documentation I wrote for the two new options is not clear enough, how could I improve it? Andy already suggested to use "backup_monday/tuesday" instead of "backup_1/2", and I agree that this makes it more comprehensible. > >Incremental backups won't work well this way, because: > >- restoring all tar files will also restore cruft > > Well with the real tar, you are right. With GNU tar (this is what Linux users > get when they believe that they use tar) it is announced to work better > although it does not work correctly because the GNU archive format is badly > designed. With star, you are wrong: > > After more than one year of testing and bug fixing, the new enhanced > diff code is ready and bug free since more than two months. > > Star now is able to identify "current" files on disk that have not been > on the disk at the time/location the backup has been made. In the near > futue, star will allow you to remove those files.... Good to know that you work on it, and yes, it seems that this would allow to take snapshots. How would you restore a snapshot? Unpack archive 1, then 2, ...? If it is sufficient to just unpack the most recent archive, how do you manage to also restore the data that had not changed and thus should not be in this archive? > >- without support for filtering or incremental backups it will > > backup unmodified files in each snapshot > > If you like a discussion, it would help to be a bit more specific. > Unless you write the exact constraints for your statement, it is impossible > to believe you because the experience tells the converse to be correct. What you described above is what I meant, but I haven't had more than a vague idea, so I couldn't elaborate. > But first, have a look at star. It is the most advanced tar archiver known > and includes the ability to filter for more than 15 years. > > >Of course, a full backup works well that way, although I prefer > >a file system that I can read without needing tar. > > Sometimes, it is nice to have the files on a FS, but in general I prefer star > for backups. Well, for me it is the other way around, so I pass and will continue to write my snapshots with the modified mkisofs. > It would be much easier to believe you, if you would behave more consistent. > > From the bottom of http://makecd.core.de/ > /*--------------------------------------------------------------------------*/ > Useful programs: > ... > Home page of vcdtools - no executable, but compiles easily with an ANSI C compiler > /*--------------------------------------------------------------------------*/ Why is that inconsistent? I said that my criteria is that people are able to compile the software; an executable is better, but not necessary. > So it looks like you _have_ a POSIX environment on your Amiga POSIX != ANSI-C, as you should know. Without installing additional stuff you cannot run configure (because there's no Bourne compatible shell) and there's no fork(). I can compile vcdtools with my normal compiler (which is _not_ gcc), but unless someone who has tried it tells me otherwise I don't believe that this would work for cdrtools. > and > you _know_ how to compl and thus would be able to compile cdrtools and > help to write a README.Amiga Of course I could do that (or at least I could figure out how to do it), but why should I? Isn't that the task of the original porter? I have no need for cdrtools on the Amiga and I have no time for it. And no, it is not because I still earn some money by selling my own shareware CD writing software on the Amiga - the money really is insignificant nowadays. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] [EMAIL PROTECTED] (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
