NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/52432: /etc/dumpdates format egregious

The following reply was made to PR bin/52432; it has been noted by GNATS.

From: Greywolf <>
Subject: Re: bin/52432: /etc/dumpdates format egregious
Date: Thu, 3 Aug 2017 19:54:26 -0700

 Hi, kre, christos, others, pardon for injecting myself into the
 discussion, but I'm following this PR with some interest.
 I'm not sure if what I say here is completely orthogonal to the
 discussion or not.
 I'm hoping the concept of a 'dump level' doesn't go away, unless
 it were to be replaced with 'f <date>', 'i <date>', or 'd <date>'
 which is really all 0, 1-9, and (n+1,n++) translate into anyway,
 but that could result in a runaway dump log (which levels nicely
 [I might point out that there may be scripts out there which rely
 on levels 0-9 *coughmaybeevenminecough*, so shifting away from
 that may be temporarily uncomfortable.]
 Having a GUID-ish (but optionally user-selectable) DevID attached
 to each device sounds to me like a workable idea and it would
 render /etc/dumpdates considerably less useless. My question here
 would be: Is there a provision inside FFS allowing for an identi-
 Tangentially, kre, you mentioned "designing a new format for dump's
 data" -- could you clarify the intent there? Did you mean the
 dump timestamp metadata (dumpdates), or did you mean the entire TOC
 format (inode maps)? [this can be taken off-line from this discussion.]
 You also mentioned the place *whither* you back up your filesystems via
 dump. I'm unclear on why the output device for the dump has anything to
 do with this -- dumpdates only references the last dump of an INput
 device. Restore uses restoresymtable to determine whether or not the
 incremental restore is of the proper date.
 Thank you both for chiming in on this. I'd forgotten about the
 vulnerability of "%s" respective to *scanf().

Home | Main Index | Thread Index | Old Index