#11 Failed to delete the .lg file after closing RecordManager.

open
nobody
None
5
2003-12-09
2003-12-09
No

I found this problem when I created RecordManager for
an exiting database and after calling the close method of
RecordManager I was not able to delete the .lg file.
I found one place when the .lg file is not closed.
In the TransactionManager.recover method
FileInputStream is not closed when method returns. The
logFile.delete() is not deleting the .lg file becasue there
is an open connection to that file. This method should
have a try/finally clause where fis is closed before the
method returns.

Discussion

  • MTe23

    MTe23 - 2006-09-01

    Logged In: YES
    user_id=1588533

    Will this bug be fixed in the next release? Cause I got the
    same problem and we established already a fix for it.
    Or isn't it a failure out of your view?

     
  • Alex Boisvert

    Alex Boisvert - 2006-09-01

    Logged In: YES
    user_id=982

    Thanks for the report! I had been wondering about that one
    for a while.

    cheers,
    alex

     
  • Nobody/Anonymous

    Logged In: NO

    Hello Boisvert.

    Here is a detailed bug description and the solution, how we
    fixed it.
    If you create instances of a btree that exists on the hd,
    but its header is corrupt, the library exits with a
    java.lang.Error which is not an Exception (its a throwable,
    that's not nice).
    Because we use your implementation in our application, it
    can not exit, we must remove the file and generate a new
    one.

    Due to the fact the Constructor opens InputStreams, the
    file can not be deleted but it must be, because we want to
    generate new ones.

    So, I want to generate a new BaseRecordManager.

    Constructor.
    public BaseRecordManager(String filename)
    throws IOException {
    _file = new RecordFile(filename);
    _pageman = new PageManager(_file);
    _physMgr = new PhysicalRowIdManager(_file, _pageman);
    _logMgr = new LogicalRowIdManager(_file, _pageman);
    }

    The Constructor of the RecordFile(filename) can fail in the
    constructor of the TransactionManager by calling recover().
    ObjectInputStream ois = new ObjectInputStream(fis); OIS can
    fail on corrupt files, and due to the fact that it is not
    closed, the file can not be deleted.
    The ois and the fis must be closed on exceptions.

    private void closeInputStreams(ObjectInputStream ois,
    FileInputStream fis) throws IOException {
    if (ois != null)
    ois.close();
    if (fis != null)
    fis.close();
    }

    It would also be nice if you throw IOExceptions instead of
    java.lang.Error.
    Second, the Constructor of PageManager(RecordFile _file)
    can fail, because of the same header problem.

    PageManager(RecordFile file) throws IOException {
    try {
    this.file = file;
    // check the file header. If the magic is 0, we
    assume a new
    // file. Note that we hold on to the file header
    node.
    headerBuf = file.get(0);
    if (headerBuf.readShort(0) == 0)
    header = new FileHeader(headerBuf, true);
    else
    header = new FileHeader(headerBuf, false);
    } catch (Error e) {
    file.forceClose();
    throw new IOException(e.getMessage());
    }
    }

    I added the catch, because if the header is wrong, the
    FileHeader class also throws an Error. If so the RecordFile
    should be closed and an IOException should be thrown.
    Then all InputStreams are closed and the files can be
    deleted and generated again.

     
  • Joel

    Joel - 2009-09-09

    Any update on this? I'm hitting the same issue and would love to see this get fixed.

    -Joel

     
  • mstraps

    mstraps - 2010-02-05

    We are hitting this bug too and also have to patch jdbm locally.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks