The point is that it barely miss nothing to have a browsable uncompressed rsynced backup folder for people willing to retrieve files from that directly.

It's the default rsync behavior.

I'm pretty sure every point you are presenting could be dealt in another way.

Attrib files could have a really proprietary name to avoid collisions (".backuppc_internal_attrib-backup-UUID").

Attrib files could be stored in another meta directory somewhere else under pc/localhost/ (and, regarding the volume saved on a backup, i really doubt that a few more I/O would have a significant impact).

...

As said previously, that would allow these two nice features :

- allowing to plug an external drive with a backuppc uncompressed rsync-ed backup folder on another computer if the main server crash (allowing a quick recovery of some files - of course, one can "unmangle" the directory, but really, it's an unnecessary manipulation, especially if it can be easily avoided from the start)

- allowing to pusblish (sshfs, nfs, smb, ...) a read only share of this uncompressed rsync-ed backup folder.

I really like a lot of features in backuppc, the internal rsync storage behavior is the only one i strongly disagree with, mainly because i really thing it can be easily be just a simple and regular rsync backup path.

Thanks anyway for your previous answer.

Regards.

--
Serge.

On Mon, Sep 24, 2012 at 8:35 PM, <backuppc AT kosowsky DOT org> wrote:

Serge SIMON wrote at about 19:01:54 +0200 on Monday, September 24, 2012:

 > Hello,
 >
 > BackupPC seems a great tool.
 >
 > The only - main - drawback for me is the file name mangling on (mainly
 > rsync) backups (backuppc adds an "f" to every folder of file backuped).
 >
 > I've read the few information about that (that it wasn't activated on old
 > versions, and why it has been), but i really think it's a bad design
 > choice. "attrib" files could have been stored elsewhere for example, and so
 > on.
 >
 > The problem is that the rsynced folder is not directly usable once
 > backuped, one can only restore from the (great) backuppc front-end, whereas
 > there are several use cases where this is not possible or pertinent (server
 > crash > remount external backup drive elsewhere and willing to immediately
 > access backuped files, or just willing to share as read only the backup
 > folder on the network).
 >

One is not supposed to use rsync directly to restore from the pc tree
for mulitple reasons, including the fact that if you use a compressed
pool, the files will be compressed. Also, you lose all the key
metadata like timestamps, ownership, permissions. Similarly, special
files, hard/soft links, etc. won't be treated properly. Finally, the
prefix-f is not the only potential change. Various non-alphanumeric
characters are also substituted by their hex representations which
would also mess up rsync. Moreover, there is good reason to keep the
attrib file in the same tree (it saves on directory reads), hence the
need for f-mangling.

Basically, the only use case for restoring any file directly from the
pc tree is if you are an expert user well-aware of the above
limitations, in which case undoing the extra 'f' should not be a
problem.

 > So : how could i deactivate this file mangling thing ? (at first glance in
 > the code, it seems to be hard coded !).

It's hard coded. There is no reason to disable it. It would mess
things up.

 > If it is not possible to deactivate this behavior, could it be either
 > removed, either made configurable in a next version ?

No --  It's a terrible idea that shows a complete lack of
understanding of how backuppc works and the whole purpose of the pc tree.
Feel free to rewrite the code to function otherwise but I can't think
of any reason why the code should be officially changed and I can
think of lots of reasons not to.

 >
 > Thanks in advance for any answer / clue about this.
 >
 > Regards.
 >
 > --
 > Serge.

 > ------------------------------------------------------------------------------
 > Live Security Virtual Conference
 > Exclusive live event will cover all the ways today's security and
 > threat landscape has changed and how IT managers can respond. Discussions
 > will include endpoint security, mobile security and the latest in malware
 > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 > _______________________________________________
 > 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/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
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/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
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/