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

[Greywolf <greywolf%starwolf.com@localhost>]

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
limits).

[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-
fier?

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().

--*greywolf;