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 [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
