Deleting data directory while DB is open doesn't raise any errors

[Wiezzel]

When the database directory is removed while a DB is open, none of the DB operations raise any errors. The data seems to be stored correctly. But when the DB is opened again, the data is (obviously) gone. That kind of silent failure is confusing for the user.

Steps to reproduce:

fn delete_db_dir() {
    let path = PathBuf::from_str("./db").unwrap();
    let db = libmdbx::Database::<libmdbx::WriteMap>::open(&path).unwrap();
    std::fs::remove_dir_all(&path);

    {
        let tx = db.begin_rw_txn().unwrap();
        let table = tx.open_table(None).unwrap();
        tx.put(&table, "key", "data", Default::default()).unwrap();
        tx.commit().unwrap();
    }

    {
        let tx = db.begin_ro_txn().unwrap();
        let table = tx.open_table(None).unwrap();
        let data: Vec<u8> = tx.get(&table, "key".as_bytes()).unwrap().unwrap();
    }

    drop(db);
    let db = libmdbx::Database::<libmdbx::WriteMap>::open(&path).unwrap();

    {
        let tx = db.begin_ro_txn().unwrap();
        let table = tx.open_table(None).unwrap();
        let data: Vec<u8> = tx.get(&table, "key".as_bytes()).unwrap().unwrap();  // panic: called `Option::unwrap()` on a `None` value
    }
}

[erthink]

In short, that's the nature of Unix.
Please use the mdbx_env_delete() with MDBX_ENV_ENSURE_UNUSED or MDBX_ENV_WAIT_FOR_UNUSED to delete a DB.

However, it will always be possible to delete files bypassing the libmdbx API, and the Unix/Linux kernel will support inodes of deleted files and continue an operations until the descriptors are closed. So libmdbx will continue to work with an open database without noticing the such deletion.

Technically, it is possible to track such deletion by inotify or by checking the st_nlink > 0 after fstat() syscall. However, I don't think it's worth adding such checks to the storage engine, as this will introduce significant overhead costs, and using a DB in this mode is one of an acceptable cases.

[Wiezzel]

However, I don't think it's worth adding such checks to the storage engine, as this will introduce significant overhead costs, and using a DB in this mode is one of an acceptable cases.

Fair enough.