Write log of chkdsk activity to checked media

[Lewis Rosenthal]

It would be consistent with OS/2's behavior for HPFS and JFS, at least, to write a log of chkdsk activity (even if only plain text, and without the need for a special log formatter) to the root of the checked media.

[Valery V. Sedletski]

In r175, I implemented writing chkdsk.log file in HPFS CHKDSK format. It can be viewed by chklog/pmchklog CHKDSK log formatter, written by IBM. Atm, the log is written into memory, and at the end, it is flushed to disk via DosWrite?. So, it does not yet work when started from autocheck (IFS is not yet initialized, so DosWrite? is not available), but works if started manually. Will change to directly creating the directory entry and allocating clusters for the log file, by means of CHKDSK only.

[Valery V. Sedletski]

Starting from r179, We're using internal CHKDSK functions to create chkdsk.log file, so CHKDSK log creation should work when doing autocheck. But there's still a problem exist when updating directory entry for chkdsk.log on subsequent CHKDSK runs. So, the timestamp of chkdsk.log is not updated if it is not created from scratch. Also, starting from r181, we don't use file API's when doing CHKDSK. Instead, we use internal CHKDSK functions for setting e.g. file data (PATHINFO). So, we don't call IFS file functions when CHKDSK is in progress (which means that the volume is remounted in special mode, when files on it are inaccessible, except for working with a volume file, opened in DASD mode). Also, starting from r180, we deny access to a volume, when it is being formatted or checked (when it is remounted in MOUNT_ACCEPT mode). All these prevent different kinds of traps.

Also I added a signal handler for SIGINT/SIGBREAK/etc. signals which should remount volume in usual mode if CHKDSK is crashed, or interrupted by Ctrl-C or Ctrl-Break. But for some reason, the signal handler is not called. The problem may be that CHKDSK is a 16-bit application, but it calls a chkdisk() 32-bit function (via CHKDSK() 16-bit wrapper) to do disk checking. So, it may attempt to install a 32-bit signal handler, but the application is 16-bit, so, some problems may exist. I still don't know, how to work around this. Atm, the volume is not remounted if CHKDSK is interrupted, so, it remains inaccessible. You should either, do a complete CHKDSK pass, or reboot.

The download link for r183 to new FAT32 build is at http://trac.netlabs.org/fat32/.

[Valery V. Sedletski]

Added capability to read/write/setfileptr on volumes, opened with OPEN_FLAGS_DASD mode (needed for FORMAT). This is since r184.

[Lewis Rosenthal]

Testing against r210, after a manual chkdsk pass of a clean USB stick, I get an 8-byte log, which when loaded into pmchklog tells me:

********** Log Entry 1 **********
Message Number: 2408
Message Text:  (text not available)

What am I missing?

[Valery V. Sedletski]

2lewisr: You need the updated message.txt for log formatter (It needs new messages). This message.txt file is supplied with the binaries in \os2\docs\fat32 directory. The 2408 message is "File Allocation Table (FAT) is ok.". But this is strange for me that you have a 8-byte log. I usually have a 20-byte log on a clean media, like this:

********** Log Entry 1 **********
Message Number: LOG02408
Message Text: File Allocation Table (FAT) is ok.  
 
********** Log Entry 2 **********
Message Number: LOG02404
Message Text: The correct free space is set to 1212393 allocation units.  

[Lewis Rosenthal]

Okay, installing the optional text documentation package in the WPI gets message.txt copied to \OS2\DOCS\FAT32. Copying it from there to \OS2\HELP gets me the first log entry, properly formatted:

********** Log Entry 1 **********
Message Number: LOG02408
Message Text: File Allocation Table (FAT) is ok.

Checking stick again, this time with /F...

Okay. This time I get:

********** Log Entry 1 **********
Message Number: LOG02408
Message Text: File Allocation Table (FAT) is ok.  
 
********** Log Entry 2 **********
Message Number: LOG02404
Message Text: The correct free space is set to 1890678 allocation units.  

Testing again, without /F, I get the same pair of entries. My first test was done with PMCHKDSK. Maybe that's it. I'll try some more, but I consider this ticket closed. Thanks for adding this valuable feature, Valery!

In any case, I suggest we ensure that message.txt is installed to the proper location, and not stored with the text documentation.

[Valery V. Sedletski]

Then where is the appropriate location for message.txt? As I can see, it should be in pmchklog installation directory, but why \os2\help? Or, it could be located somewhere in DPATH?

[Lewis Rosenthal]

It appears that we search DPATH and HELP. The only problem with replacing the original message.txt in \OS2 is that during a WarpIN uninstall, we don't want to remove message.txt altogether, or else we lose all of the original messages in the file.

[ataylor]

A couple of problems here. First of all, message.txt ships with the log formatter, not with OS/2, and so it has no fixed location that it could be placed in. (FWIW, current ArcaOS betas put it in \sys\bin as the documentation says that it should be in the same directory as (pm)chklog.exe.)

Second, it's probably not wise to simply copy over the existing message.txt wholesale: if FAT32 adds its own messages, there's no guaranteeing that other third-party IFS drivers might not also do the same. Do we treat it as a static file, or as a dynamic (updateable) one?

As CHKLOG is an optional application, which can't be guaranteed to be installed, and whose location can't be guaranteed if it is, I think the best approach is to simply leave it up to the user to update message.txt. After all, they would presumably have had to install the formatter themselves anyway, so they know where it is (we don't). And they're presumably reasonably technical if they did so anyway.

For distributions like ArcaOS, we can ship a FAT32-aware message.txt from the get-go and thus avoid the issue entirely.

My recommendation: simply include message.txt in the FAT32 doc directory, and let the user update their CHKLOG files if necessary. (And if they're not technical enough to do that, why would we expect them to be using CHKLOG in the first place?)