Re: kern/47748: Invalid file on ffs

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

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

From: jnemeth%victoria.tc.ca@localhost (John Nemeth)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%NetBSD.org@localhost, 
gnats-admin%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost, frederic%fauberteau.org@localhost
Cc: 
Subject: Re: kern/47748: Invalid file on ffs
Date: Sun, 21 Apr 2013 16:40:02 -0700

 On Aug 4,  6:22pm, David Holland wrote:
 }
 } 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
 } Date: Fri, 19 Apr 2013 06:12:54 +0000
 } 
 }  On Thu, Apr 18, 2013 at 10:30:11AM +0000, Fr?d?ric Fauberteau wrote:
 }   >  >  > root@trashware:~$ rm /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+^F
 }   >  >  > rm: /usr/pkgsrc/ham/tfkiss/pkg/CVS/K+: No such file or directory
 }   >  >
 }   >  >  You could 'ls -li' the file, note the inode, then "shutdown now" to
 }   >  >  single user mode, umount(8) the file system, clri(8) the inode, then
 }   >  >  fsck(8) -fp the file system, and reboot.
 }   >  
 }   >  I could not 'ls -li' the file since syscalls failed on it. But I should 
 }   >  try a fsck in single user mode before submitting PR. It does not 
 }   >  enlighten me on what was the problem with this file but it corrects the 
 }   >  fs.
 }  
 }  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.
 
 }  (Without the zero byte, you'd probably have been able to name the file
 }  with autocompletion, and ls -l would have worked. Although I remember
 }  once a long time ago accidentally getting a file with a newline in its
 }  name, which turned out to be surprisingly hard to get rid of. I think
 }  I ended up needing to write a C program that called unlink(2).)
 
      I had a situation once where a filename had a "/" in it.  Under
 normal conditions this would be impossible.  The situation arose as the
 machine was an NFS server, and the client was a Mac.  MacOS used ":" as
 a path seperator, so a "/" had no special meaning to it.  My solution
 was to clri and fsck as somebody else suggested.  This happened around
 1992 give or take a year.  I would hope that this wouldn't be able to
 happen with a modern system.  I don't recall which machine it was on
 now, but the server was running either SunOS 4.x or Ultrix 3/4 (VAX).
 
 }-- End of excerpt from David Holland