On 08/26 03:40 , Holger Parplies wrote:
> Carl Wilhelm Soderstrom wrote on 2011-08-25 13:40:47 -0500 [Re:
> [BackupPC-users] Feature request]:
> > I might suggest 'root' instead of 'full' or '/'; because a restore starting
>
> (I'm always confused by your usage of ";" ...)
Heh. Sometimes I overemphasize the pauses & junctures in my train of
thought. I realize it's mediocre grammar when I go back and re-read it, but
I don't usually proofread and edit my mails heavily. ;)
> 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 ;-).
This is a good point.
> 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.
True. I agree that it should be a sensible default for most people. This
isn't something that *needs* a lot of customization capability (especially
considering how long we've gone before anyone was inconvenienced enough to
write an e-mail about it).
> 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.
This is indeed a sensible default. I have had situations where I needed to
retrieve several files tho (possibly from different machines), and I sometimes
forget to delete a file after using it, and so I rename files to something
that describes what is in them so I can avoid confusion with a glance.
> In my experience, deleting or
> rearranging parts of overly long filename suggestions can be just as
> annoying as having to fill out "obvious" information.
Agreed.
> 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.
On 08/26 12:03 , Adam Goryachev wrote:
> Thus, a filename of bpc_restore_$host_$number_$share.(tar|zip)
>
> IMHO, if you selected one or more files from a single share (most cases
> I suspect), then you show that specific share name.
> If you select one or more files from multiple shares then use the share
> name of "multiple" or exclude the share name.
I agree that backup numbers are nicely shorter than date numbers (even
'20110829' is longer than '1036'); but OTOH I don't have a miserable clue
what that backup sequence number means, whereas I do know what a date is,
and that's what the end-user cares about anyway. So rather than have me do
the translation between backup number and date in my head (and get it
wrong), I believe it would be far superior to include the date in the
filename.
As a simple improvement and compromise, I would support something like
"bpc_restore-<date>-<host>.<ext>". For example
"bpc_restore-20110829-www.foobar.com.tar". I do however realize that this is
unpleasantly long already for some applications.
--
Carl Soderstrom
Systems Administrator
Real-Time Enterprises
www.real-time.com
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
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/
|
