NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
bin/50434: dumpdates corrupted with long file system path names
>Number: 50434
>Category: bin
>Synopsis: dumpdates corrupted with long file system path names
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: bin-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Nov 16 16:10:00 +0000 2015
>Originator: Louis Guillaume
>Release: NetBSD 7.0
>Environment:
System: NetBSD maat.zabrico.com 7.0 NetBSD 7.0 (GENERIC) #0: Wed Sep 30 19:27:26 EDT 2015 louis%maat.zabrico.com@localhost:/usr/obj/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
After updating my filesystems to using LVM, I'm having a strange problem with /etc/dumpdates. Here's a recent sampling of dumpdates:
/dev/rraid0a 0 Sat Nov 14 15:58:41 2015
/dev/mapper/rvg0 - Wed Dec 31 18:59:59 1969
/dev/mapper/rvg0 - Wed Dec 31 18:59:59 1969
/dev/mapper/rvg0 - Wed Dec 31 18:59:59 1969
/dev/rraid0a 1 Sun Nov 15 02:45:00 2015
/dev/mapper/rvg0 - Wed Dec 31 18:59:59 1969
/dev/mapper/rvg0-var 1 Sun Nov 15 06:18:47 2015
This results in the following message during a dump:
Unknown intermediate format in /etc/dumpdates, line 1
Seems to be due to the DUMPINFMT constant, where the "name" field is only 16 in length. In /usr/src/include/protocols/dumprestore.h:
#define DUMPINFMT "%16s %c %[^\n]\n" /* inverse for scanf */
>How-To-Repeat:
Dump a filesystem, whose path is longer than 16 bytes. Observe corruption in /etc/dumpdates. This may require an intial dump and then another dump that attempts to read/update the dumpdates file.
>Fix:
Unknown. Possibly change DUMPINFMT as a workaround.
Home |
Main Index |
Thread Index |
Old Index