Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!sco!md
From: md@sco.COM (Michael Davidson)
Newsgroups: comp.unix.xenix.sco
Subject: Re: 1Gbyte file on a 130Mb drive (fsdb)
Keywords: big file fsdb
Message-ID: <12754@scolex.sco.COM>
Date: Tue, 25 Jun 91 18:24:59 GMT
References: <124@comix.UUCP>
Sender: news@sco.COM
Distribution: na
Lines: 49


jeffl@comix.UUCP (Jeff Liebermann) writes:

>How does one deal with a bogus 1Gigabyte file?
>I have a Xenix 2.3.3 system that has ls magically
>declare a 45Mb accounting file as 1Gbyte huge.

>ls	declares it to be 1Gb big.
>du	agrees.
>df -v	gives the correct filesystem size.
>fsck	"Possible wrong file size I=140" (no other errors).

>To add to the problem, I'm having difficulty doing
>a backup before attacking.

>compress  bombs due to lack of working diskspace.
>tar, cpio, afio   insist on trying to backup 1Gb of something.
>dd  at least works and I can fit the 130Mb filesystem on one
>QIC-150 tape (whew).  To add to the wierdness, all the
>reports generated by the application (Armor Systems Excalibur
>Acctg) work perfectly as if nothing were wrong.

It is possible that the application generated a "sparse"
file by seeking to a 1Gbyte offset and writing some data.
If this is really the case then it is very unfriendly behaviour
on the part of the application (for all of the reasons you
outlined above).

>Obviously a job for fsdb.  However, every book I own and
>the SCO ADM manuals give a terse and/or trivial example of
>fsdb usage.  Can anyone recommend a book that has a detailed
>explanation for using fsdb?  Any brilliant advice?

Actually I think that all you need here is "rm". If you know what
size the file *should* be (assuming that the 1Gbyte size is
in fact an error and not something that the application did
deliberately) and you care about the current contents of the
file you can just use dd to copy the appropriate amount
of data from the 1Gbyte file to a temporary file, remove the
offending file and move the temporary file back to whatever
name the accounting file should have. You might want to run fsck
afterwards just for luck, but since your previous fsck run only
reported a possible file size error there should be no problems
(ie you didn't have any "duplicate block" or "bad block" errors
did you?) If you don't care about the current contents of the
file just remove it.

I'm afraid that there isn't any really good documentation on fsdb
that I know of .....