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
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/