[Info-vax] Request description of UFS for VMS person

[Bob Eager]

On Wed, 29 Apr 2009 03:17:31 UTC, David J Dachtera 
<djesys.no at spam.comcast.net> wrote:

> Bob Eager wrote:
> > 
> > On Fri, 24 Apr 2009 12:52:25 UTC,
> > koehler at eisner.nospam.encompasserve.org (Bob Koehler) wrote:
> > 
> > > In article <176uZD2KcidF-pn2-Q7WHbUsddkvE at rikki.tavi.co.uk>, "Bob Eager" <rde42 at spamcop.net> writes:
> > > >
> > > > No. I've always been amazed that VMS allowed it, since it compromises
> > > > the file structure.
> > >
> > >    It's helpfull when trying to recover files lost in a corrupt
> > >    directory file due to a block read error.  You can intentionally
> > >    blow away the directory file and then analyze/media/repair will
> > >    move all those files to [syslost].
> > >
> > >    As long as analyze/media/repair finds a corrupt directory it will
> > >    not try to figure out which files are lost.
> > >
> > >    I've not had the pleasure of losing a block in a directory file in
> > >    any other OS.  I think on some you'ld have to reformat the disk and
> > >    restore from backup.
> > 
> > Unix just does it a different way. You can wipe the inode for the
> > directory, thus orphaning the file, and then an fsck will pick up the
> > files and put them in /lost+found.
> 
> ...but, you've still got a problem. In <mount-point>/lost+found you find
> a file named for its inode number. Unless you:
> 
> A. only lost the one directory containing a single file
> 
> ...or...
> 
> B. include lists of files and inode numbers in your daily backups

Oh, I agree. But that's a separate problem, and nothing to do with the 
way one got there (clearing the inode), because (compared to VMS) the 
inode is lightweight and contains no clue to the filename.
-- 
Bob Eager