Mark Giuffrida writes:
> First off, we get this all the time too and I believe its normal behavior.
> Here is whats happening:
>
> An application opens file for logging errors and holds the descriptor open.
> It doesn't have errors to log to it, so the first write has never occurred.
> Chances are it will never have any errors to log, so basically the first block
> of data for the file has not been sent to the fileserver.
>
> Now lets look behind the scenes. When the file is created and opened for
> writing, the fileserver allocates a directory entry for the file and inserts
> it into the directory structure. For efficiency reasons, it waits until the
> first block of data has arrived before it allocates the file vnode. Thus,
> when the fileserver is salvaged, you have a directory entry with no
> corresponding vnode and the salvager doesn't know what to do with it other
> than delete it.
>
> Probably what should happen is there should be some sort of initial state set
> so that the salvager can recognize the condition and simply ignore it.
AHAH! When first invoked, gopher creates and closes a zero-byte
.gopherrc. Unless bookmarks are created, it stays zero-byte.
This is obviously unrelated to my original volume corruption problem.
I still haven't heard what people consider prudent maintenance
practice for running fsck and salvage periodically.
-Rick
--
|Rick Cochran 607-255-7223|
|Cornell Materials Science Center [EMAIL PROTECTED]|
|E20 Clark Hall, Ithaca, N.Y. 14853 cornell!msc.cornell.edu!rick|
| "Workstations - I bet you can't eat just one!" |
