Re: kern/47748: Invalid file on ffs

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

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