Re: kern/47748: Invalid file on ffs

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, frederic%fauberteau.org@localhost
Subject: Re: kern/47748: Invalid file on ffs
Date: Fri, 24 May 2013 08:15:30 +0000

 On Sun, Apr 21, 2013 at 11:45:05PM +0000, John Nemeth wrote:
  >  }  It looks to me like it was probably four (or maybe more) characters
  >  }  long with a zero byte as the fourth character. There is no way to name
  >  
  >       Except that it should be impossible to create such a file no
  >  matter what an application does.  If a zero byte were to ever appear in
  >  a filename it would represent a serious bug in the filesystem code or
  >  memory corruption.
 
 You'd think so, yes. On the other hand, clearly the file was created
 from an uninitialized string or the name wouldn't have begun with
 K+\x6.
 
 Another possibility is that the next byte of the filename was one of
 the magic values > 0x80 that sh's parser uses for internal signalling.
 That would likely make it impossible to address the file from the
 shell, with or without autocompletion. (If the shell was sh, anyway.)
 I could also imagine 0xff confusing some shells, particularly csh.
 
 But if the filename merely contained a control character, fsck
 wouldn't have removed it. Or so I'd think anyway. All I see in
 fsck_ffs is checks for embedded 0 and '/'.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost