Re: [BackupPC-users] Feature request

[Holger P. <wb...@pa...>]

Hi,

first of all, it seems to be *possible* to implement [without major code
changes], in case anyone except me was wondering ;-).

Carl Wilhelm Soderstrom wrote on 2011-08-25 13:40:47 -0500 [Re: [BackupPC-users] Feature request]:
> On 08/25 02:22 , Brad Alexander wrote:
> > You could substitute "Full" for a root-level restore... So it could be
> 
> sounds reasonable.
> I might suggest 'root' instead of 'full' or '/'; because a restore starting

(I'm always confused by your usage of ";" ...)

> at / is not necessarily a restore of everything. [...]
> 
> The suggestion of not using a sharename for restores starting from the root;
> perhaps could be restated as something like " '/' characters shall be
> converted to '_' characters except for the leftmost one, which shall be
> omitted". this would end up omitting the sharename (or path or whatever it
> ends up being) if it's just '/'.
> 
> [...]
> 
> This may be a case where empirical testing serves better than theoretical
> wrangling. Let's see if long filenames actually occur and cause problems;
> and how drastic the solutions to them need to be.

well, let's consider where we are. We're in the CGI interface, where someone
marks a list of files or directories and selects to download them. So we not
only *definitely* have arbitrarily long paths (depending on where within the
backup the file(s) is/are that are requested), we have an arbitrary amount of
them. This can *easily* exceed maximum path lengths and test browsers for
buffer overflow vulnerabilities ;-).

Moreover, what is being suggested is merely a *convenience* for the person
downloading the tar/zip. Let's not turn it into an *inconvenience* for him.

Personally, I use the download function for retrieving files from backups
that I need immediately (rather than restoring them in-place which seems
rather error-prone). "restore.tar" is just fine for me, it's the tar of the
files I just retrieved. I untar it and remove the tar file. In the unlikely
event that I should need it again, I can always re-download it (well,
presuming the backup hasn't expired, but I'm thinking about a time frame of
minutes, here). Actually, I might even make a point of *excluding* files named
restore.tar or restore.zip from my backups, though for that, names like
BPC_restore.{tar,zip} might be better.

For what I think you have in mind I would always use a BackupPC_tarCreate
invocation.

Of course, your preferences may vary. There might be situations where
downloading an "archive" type tar file via HTTP is both practical and the
most simple solution. In this case, you won't want a name like "restore.tar",
but you might just as well have different preferences/requirements than
whatever BackupPC is going to suggest. In my experience, deleting or
rearranging parts of overly long filename suggestions can be just as
annoying as having to fill out "obvious" information. The best solution
would be to have the suggestion customizable (as in "%h-%n-%s"), but that's
probably a lot of work for little effect (and it should strictly be a per-host
setting). As a simpler solution, I'd suggest "restore-%h-%n" (where %h is the
host name and %n the backup number) (and the .tar/.zip suffix, of course). If
the date of the backup is easily available to the code in question, I'd prefer
the date over the backup number, though there are bound to be people who have
more than one backup on the same date (happens to me if one backup is delayed
past midnight and the next one isn't). Maybe date + backup number. Remember
that even though you might only have 9 backups the backup numbers aren't
intended to wrap around, so they would still be unique for one host unless
you start over with a fresh pool.

Regards,
Holger