Holger Parplies wrote at about 02:05:28 +0200 on Tuesday, September 1, 2009: > Hi, > > Jeffrey J. Kosowsky wrote on 2009-08-31 18:15:07 -0400 [Re: [BackupPC-users] > Problems with hardlink-based backups...]: > > Les Mikesell wrote at about 15:23:41 -0500 on Monday, August 31, 2009: > > > Jeffrey J. Kosowsky wrote: > > > > [...] > > > > I guess I can't answer your question without knowing what use cases > > > > you are worried about. > > > > > > All of them.
Name the top 10 that worry you most so that I can get a feeling for how hard they are to solve. Again, I can't address a generic fear. > > that is the point, precisely. You need to deal with *all of them*. Anything > that can happen, whether you can anticipate it or not. > > > > Filesystems have journal/check mechanisms. How would you > > > provide the equivalent? > > > > I am certainly not a database expert but I am aware enough to know > > that such integrity issues are dealt with all the time in real world > > databases > > Wrong. That is what you are missing. We're not talking about in-database > corruption, we're dealing with inconsistencies on the application level. The > database and its related tools don't know anything about the *meaning* of the > data BackupPC puts inside the database. You can't have a > > FOREIGN KEY (filename) REFERENCES external-file-path ON DELETE RESTRICT > > (i.e. as long as something references the file, the file system may not > delete > it). Do you understand that? Well you simply don't include anything in BackupPC that would delete a file before checking that there are no active references in the database. In fact, I believe that BackupPC only ever deletes or even renames pool files during the BackupPC_Nightly run. So, the new version of BackupPC_Nightly would have to check the database before deleting files which is how you would want to do it anyway to identify orphan files. I fail to see why this is that so complicated? And if you are worried about programs other than BackupPC deleting the file then the same can occur today since I could go into topdir and start creating all types of havoc by overwriting pool files or deleting attrib files. > > > I am only suggesting that the current implementation seems to be difficult > > to extend to address other relatively common and standard backup > > requirements. > > Fair enough, and agreed. > > > Let's all keep an open mind, especially since we are all far from > > committing > > development resources to any path. > > Discussions in this length *are* development resources. > You are free to ignore this thread... ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
