VACUUM statement results in unusable database file.

[tesneddon]

This is moved here from #1:

On 03/16/2013 05:52 PM, Tim E. Sneddon wrote:

This is great news! I'm glad to hear you've got a working environment. I
was looking at some of my notes from back when I originally began the
port and one of the problems I noticed was in the VACUUM command. After
executing it the database file became unusable. I didn't get to figuring
it out, but it was a known problem.

This seems to be caused by an SS$_ACCONFLICT returned from the qio to
truncate the file. I'm not sure when you can get this. The section of
the doc I looked up is not very specific about SS$_ACCONFLICT being
returned in the IOSB. But there is this:

The truncate subfunction normally requires exclusive access to the file
at run time. This means, for example, that a file cannot be truncated
while multiple writers have access to it.

An exception occurs when a truncate subfunction is requested for a
write-accessed file that allows other readers. Although the truncate
subfunction returns success status in this instance, the actual file
truncation (the return of the truncated blocks to free storage) is
deferred until the last reader deaccesses the file. If a new writer
accesses the file after the truncate subfunction is requested, but
before the last deaccess, the deferred truncation is ignored.

What I can see (when in the debugger I changed the return code to
SUCCESS) is that the file size didn't change at all. But with that
hacked return code the db seems to stay intact. On the other hand, I'm
not sure whether any failure to truncate needs to be an error at all.
From what I understand then releasing the disk space will not take
place but the data should have been compressed, anyway.

hb

[tesneddon]

I adjusted vmsTruncate to only return success. However, now I am getting the error:

sqlite> VACUUM;
Error: unable to open database file

I'll have to look into that further.

[tesneddon]

After some further investigation it would appear that the error "unable to open database" is because of RMS$_FNF (98962) in the open. I am currently looking into which file it is actually trying to open...more to follow.