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