We have a client where one particular file keeps growing to approx 1 gb. there appears to be no reason for this that we can find. The file is in use throughout the day with no apparent errors but when the client tries to back up the data the size of the file appears to be 1 gb. File sizes from client site are

REV86333 LK 88,635,392 21/01/04 3:40

REV86333 OV 426,804,224 20/01/04 23:33

then

REV86333 LK 1,019,533,312 26/01/04 20:07

REV86333 OV 426,731,520 26/01/04 20:07

Any ideas gratefully appreciated as this is the second time this has happened. Once the file is this large nothing appears to be able to open or fix the file (We have tried OI32 and various other editors)

Peter,

Are they scanning for viruses and including *.ov files? What happens if they exclude the *.ov filespec from scanning?

Steve

Hi Peter

What file is this? Possibly LISTS? What is the sizelock set to?

The Sprezzatura Group

World Leaders in all things RevSoft

No its not LISTS, its an application data file which is written to and read from using standard Arev commands. The table is indexed but the indexes appear to be OK.

Have you tried running VERIFYLH on that table? See Reference manual page 282. You've already said that the sizelock is set to zero. What about checking for and cleaning out unused frames? Verifylh will tell you how many you have in that table. It will also make suggestions as to what the frame size should be.

I hope this helps.

Michael Slack

We thought of this but neither Arev nor OI32 can even start running VERIFYLH, I presume due to the size of the file.

What sort of activity is happening on this file? Your timestamps show several days of activity. That's certainly enough for a file to grow to that size if you were simply writing a lot of records.

Can you dump the file? What is the modulo? Does it jive with the size of the LK file? Modulo times framesize should match the size of the OK file. What is the threshold? Maybe the threshold value is corrupted. You should be able to fix this in dump.

"Once the file is this large nothing appears to be able to open or fix the file"

What happens when you try? Do normal IO operations fail as well?

DUMP can't open the file and normal activity fails with various GFE type messages. The are maybe 20 to 30 new records a day but they are only about 3k in size.

REV86333 LK 88,635,392 21/01/04 3:40

REV86333 OV 426,804,224 20/01/04 23:33

then

REV86333 LK 1,019,533,312 26/01/04 20:07

REV86333 OV 426,731,520 26/01/04 20:07

Peter,

The DOS size of the "LK" file should calculate to the exact value of the AREV modulo of the file. The formula is as follows…

DOS_SIZE_IN_BYTES / AREV_FRAME_SIZE=AREV_MODULO

The default AREV_FRAME_SIZE is 1024.

I am suggesting that your "LK" file is being corrupted or has been corrupted. The overflow frames exist in the "OV" file.

I would attempt the following…

1) Create a new file.

2) Copy all the records from the old file to the new file.

3) Watch for any errors while copying.

Can you do a select and save the list? I am thinking that you would not be able to. Also, I am thinking that your AREV file modulo is corrupted and when the file dynamically resizes it is resizing using the corrupted modulo rather than the correct modulo, thus causing the extreme DOS file size.

I wonder if my file map utility (http://the-light.com/filemap.html) can open it. I suspect you'll have memory problems with a file that size. Can you copy records from the file?

How much free space is on the volume? Maybe you're crossing a multiple of 2 Gig barrier when you lose access. But then I'd expect a similar problem on any file needing to be expanded.

I would help if I gave the link to the download file.

ftp://www.the-light.com/pub/file_map.zip

I have a really bad case of CRS. That being said, I seem to remember that kind of corruption coming from back up programs that locked the files when Arev was running. Maybe that was some other bad memory …

View this thread on the forum...