Re: kern/47748: Invalid file on ffs

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

On Oct 14,  2:51am, David Holland wrote:
} 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.

     As far as the kernel is concerned, it shouldn't matter what the
string contains, as it is just a "label" and the kernel doesn't
interpret it.

} 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.

     It may confuse the shell, but it shouldn't confuse the kernel.

     Basically, the kernel will get a pointer to some chunk of memory.
Assuming the pointer is within the processes address space and isn't
NULL, the kernel will use it.  It will scan the string looking for "/"
which it will use a directory seperator, and it will also look for NIL
which will terminate the string (assuming the string doesn't exceed the
max length).  Pretty much all other characters are just part of a
"label" and have no special significance (the labels "." and ".." do
refer to current directory and parent directory respectively).  Given
this, there should be no way for a NIL (or "/") to get into a filename
on disk.

     As an aside, I did have a system once that managed to get a "/" in
a filename on disk.  That was interesting.  The cause was that the
system was acting as an NFS server for some Macs.  And, MacOS used ":"
as a directory seperator, so "/" had no special meaning.  I ended up
using clri to kill the inode, then let fsck clean up.  This was way
back around 1990.

} But if the filename merely contained a control character, fsck

     Although obnoxious and awkward to handle, it isn't a filesystem
error.

} wouldn't have removed it. Or so I'd think anyway. All I see in
} fsck_ffs is checks for embedded 0 and '/'.

     Those are the only characters that aren't valid in filenames.

}-- End of excerpt from David Holland