Opened 18 months ago

Last modified 18 months ago

#70 new defect

IBMWorks database fails to open

Reported by: landb Owned by:
Priority: major Milestone: Future
Component: IFS Version:
Severity: medium Keywords:
Cc:

Description

Using FAT32.IFS release 336 and opening the addressbook (aka phone) feature of IBMWorks the application opens with an apparently empty database.

It works fine in R290 and shows a populated database

the database is not damaged by the failure

Attachments (3)

pim01.txt (136.9 KB) - added by landb 18 months ago.
pim02.zip (23.4 KB) - added by landb 18 months ago.
pim03.zip (23.6 KB) - added by landb 18 months ago.

Download all attachments as: .zip

Change History (12)

Changed 18 months ago by landb

comment:1 Changed 18 months ago by landb

Attachment pim01.txt shows the attempt to open the database.

System R336 with trial version BL5 unzipped on top; running OS4 debug kernel and /monitor option for FAT32.IFS; T61 used as a serial port terminal to collect the trace

looking for \pim\now will show the various calls to FAT32.

comment:2 Changed 18 months ago by landb

I think my comment above "no datasets are damaged" is wrong. There is a dataset in the pim\now database FPWPIM.INI which seems to vanish when trying to open the database in R336. It seems as though if the .ini file is missing it is recreated so it does not stop other versions opening the database (which is why I hadnt noticed before)

comment:3 Changed 18 months ago by valerius

Your log doesn't contain the moment of opening d:\d\pim\now\phone.dbf. I only see closing of that file in the beginning of the log. So please, take a full log. Start f32mon.exe before opening it. Or even, before starting IBM Works.

Also, you say that this .DBF file is not corrupted. But did you checked that additional files like database indexes are not corrupted too? Did you tried to recreate indexes? Also, I see opening the .INI file called D:\D\pim\now\FPWPIM.INI -- is it not corrupted too? I suspect that IBM Works may store some additional data about your .DBF file in such .INI's. So, these data may be lost, and so it closes the .DBF file.

I think my comment above "no datasets are damaged" is wrong. There is a dataset in the pim\now database FPWPIM.INI which seems to vanish when trying to open the database in R336. It seems as though if the .ini file is missing it is recreated so it does not stop other versions opening the database (which is why I hadnt noticed before)

Yes, that's what I said above: corrupting FPWPIM.INI may prevent your .DBF file to be opened.

PS: Please test ftp://osfree.org/upload/fat32/fat32-0.10-r337-os2.zip, I removed some unneeded debug messages. Also, there are some documentation updates.

comment:4 Changed 18 months ago by landb

As I said above, the absence of the>INI file did not prevent the database being opened when using version R290 of FAT32.

Sorry about the log: it's the buffer size in putty; will try to increase.

comment:5 Changed 18 months ago by valerius

Could you try taking the logs when opening the .DBF file with both FAT32 versions, so I could compare them?

Changed 18 months ago by landb

Changed 18 months ago by landb

comment:6 Changed 18 months ago by landb

OK. I increased the Putty buffer.

RUN 1: ECS22 with R290 running under OS2 kernel. G32MON started

database opened properly (I had to remove a lot of lines before and after the calls to PIM as the log was too big, but then I realised I could ZIP them)

Trace is in PIM02.zip

RUN 2: ECS22 with R337 running under OS4 debug kernel with /monitor and F32MON.

Database opens empty though I looked and the .INI file is still present

trace is in PIM03.zip

(if zips are inconvenient please say)

comment:7 Changed 18 months ago by valerius

It seems, I have a guess, why it's happening. Please try ftp://osfree.org/upload/fat32/fat32-0.10-r338-os2.zip, and see if your .DBF now opens ok.

comment:8 Changed 18 months ago by landb

Great. That works. Unfortunately doesnt solve the ticket 67 problem....

comment:9 Changed 18 months ago by valerius

Good. This is I forgot to disable a flag in IFS, which means that locking file pieces is supported. I only implemented FS_FILEIO, but not FS_FILELOCKS, so it tried to call FS_FILELOCKS and failed. Now I returned it back.

Note: See TracTickets for help on using tickets.