PMChkdsk falls to check fat32 and unifat volumes wihout any error message

[Gregg Young]

This is with a build of CS 176 without xfat. I run pmchkdsk on the drives and it opens and indicates it is checking. Leaving open for 5 plus minutes yields no change. Chkdsk from command line completes checks in 10-30 seconds.

[Valery V. Sedletski]

Yes, I know about that. Maybe, it waits for some message from CHKDSK, but doesn't get it. But I don't know, which. Maybe, someone knows?

What is CS 176? The only build without exFAT I uploaded is r269 from ​ftp://osfree.org/upload/fat32/. PMCHKDSK isn't working in the latest build too, which is r276.

[Valery V. Sedletski]

PS: On one of my machines, with MCP2 installed, pmchkdsk doesn't start at all. It blinks for a small fraction of a second and closes. Does somebody know why it could be? I tried to update pmchkdsk.exe and pmchkdsk.dll to versions from eCS 2.2, but it doesn't help.

[Valery V. Sedletski]

Heh, funny. It appears, that starting from r213, if you try doing chkdsk c: >log.txt, only messages from chkdsk.com got into the log. Messages from uunifat.dll disappear somewhere. I wonder what I could do that stout redirecting doesn't work?

[Valery V. Sedletski]

Finally fixed PMCHKDSK. It was initinstance and terminstance removed in the linker script, so uunifat.dll messages won't go to stdout. Also, fixed pie chart showing the disk space. There were wrong message numbers used, which are not understood by pmchkdsk. Now it works. Uploaded r277 at usual place.

[Gregg Young]

Confirm this is fixed with r277

[Gregg Young]

This problem is back in r280

[Valery V. Sedletski]

Just checked with r280 -- works fine on my machine.

[Gregg Young]

It now works but I had to completely uninstall FAT32 and then reinstall. This is with warpin.

[Valery V. Sedletski]

How it could be reinstalled not completely? Always need to copy all components: IFS, DLL's, EXE's, to be sure. Though, in this case, only uunifat.dll and fat32chk.exe does matter.

PS: all components check IFS and DLL versions, so buildlevel of all parts should be the same.

[Gregg Young]

I am seeing a slightly different failure on FAT32 drives. I just tried pmchkdsk on a drive with errors. It put up a dialog box saying there was lost data I hit OK. It then gave a dialog asking if it should save lost clusters as files. I tried both yes and no on separate attempts. After the dialog closed I waited 10 - 60 minutes with pmchkdsk on the screen showing checking... It never completed. Chkdsk worked fine and completed in 30 seconds or so.

[Valery V. Sedletski]

What message expects pmchkdsk to be displayed? ATM, the message 1365 is displayed: "%1 bytes in %2 user files", if recovered clusters are found. I think, 1366 "%1 bytes in %2 recovered files" is more appropriate. In case lost clusters found, message 1359 "%1 bytes disk space would be freed" is displayed. I doubt these are good, so need something more adequate.

[Gregg Young]

The error messages were fine. They aren't the problem. I have now found if I don't check the box write correction to disk the error dialogs appear and the disk check completes after closing them. However if the write correction box is checked I see the error dialogs but after closing them the disk check does not complete. Writing the corrections to disk seem to fail or perhaps doing so breaks the pipe to pmchkdsk.

[Valery V. Sedletski]

Not error messages, but OSO001 messages from CHKDSK.COM. CHKDSK.COM writes wrong message after lost data is detected, so that, PMCHKDSK doesn't complete ok (it hangs forever). As I can see, the message 1365 is displayed: "%1 bytes in %2 user files", which is wrong. I need to display the correct message.

Checking the "write corrections to disk" check box writes a "Y<CR><LF>" to a pipe. CHKDSK uses getch() function to detect "Y" or "N" chars. So, I don't see anything unusual here. The "Y/N" keypress should be properly detected.

Though, PMCHKDSK does not work on my main machine. After starting "pmchkdsk w:", it closes immediately. I wonder what should be the problem.

[Valery V. Sedletski]

It seems, I fixed it in r349. It appears to use the getch() function for 'Y/N' query, which seems to be incompatible with pipes. I changed it to getchar() function which works. At least, after the "Covnert lost changes to files (Y/N)" query, I see the message about number of chains converted, and a piechart. So, now it works.

[martini]

Hi

It seems fixed and there haven't been a reply in two years. If the error persist with the latest test version (0.10 r383), please reopen the ticket.

Regards