Author Topic: Avoiding Windows 7's CHKDSK?  (Read 2106 times)

Valery Sedletski

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 11
  • Posts: 73
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #15 on: May 05, 2017, 12:52:20 pm »
For an old FAT16-based MP3 player, it is better to use new fat32.ifs with FAT16 support. The VFAT LFN's are now supported on FAT12/FAT16 too. So no need to use any REXX utilities to convert LFN's, or vfat2ea, it is all obsolete now. Please look at http://trac.netlabs.org/fat32/ for a download link.

And, it is possible that fat32.ifs will behave differently than the kernel FAT, so your error will be gone.

PS: The reserved bytes in directory entries which are used to store the EA's pointer by OS/2, are reused by M$ on FAT32 as a high word of a cluster number (because cluster number is 32-bit on FAT32). On FAT12/FAT16, these bytes are not used as cluster number is 12 or 16 bits, and no high word is needed. So, it should play no role.  And you say that the drive is considered *damaged*, not dirty by windoze, so I doubt it's something with unused bytes in dir entries. As I can see, the trash in dir entries does not prevent the disk to be mounted.

PPS: is it possible to upload the disk image somewhere? (I could suggest my ftp for upload, if so)

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 24
  • Posts: 657
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #16 on: May 05, 2017, 06:08:40 pm »
Quote
The word "damaged" (damaged disk, e.g. bad sector) occurs in a next dialog window, but is not relevant and blurred the memory.

The fact that flash disks don't have sectors still has to be taken into account.  If a flash cell becomes damaged, worn out, and the wear levelling firmware can't allocate a replacement then to the OS, especially windows, it will appear as a bas sector and trigger the chkdsk subsystem.

For a longer discussion on this see: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #17 on: May 06, 2017, 01:48:17 pm »
I have removed my reply with the requested images.

Most likely it's solved. Unverified, but there may be more than one DIRTY-bit (/byte) since OS/2's FAT. If e.g. Windows 7 uses both, but OS/2 doesn't, then you may be triggering a CHKDSK. So FAT32.IFS can be a solution too, if FAT32 is aware of all modern flags and if it indeed doesn't break a FAT MP3 player.

DFSee should show that it's a DIRTY drive, but I wouldn't have noticed the DIRTY-flag now because images were created after a possible write operation, nor would I have noticed a "second" DIRTY-flag. DFSee shoudl be able to set the status to CLEAN.

No tests nor verifications yet, including a test of FAT32.IFS. So far a simplified conclusion is that the number of DIRTY-flags isn't one.

Valery Sedletski

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 11
  • Posts: 73
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #18 on: May 06, 2017, 02:13:45 pm »
Dirty flag on FAT32 is the same as on FAT16 -- it is a bit set in the 1st FAT entry. On exFAT, though, it is set in the boot sector instead, but this is not the case.

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #19 on: May 06, 2017, 09:40:03 pm »
Phrases like "second DIRTY bit" were simplified, and refered to a second setting near the expected (first) "DIRTY bit". I've now verified it (with anUSB flash drive, and FAT older than FAT32, and OS/2's FAT):

In FAT mode, DFSee's Set FAT status Clean sets both settings right. The expected classic DIRTY bit, and the unexpected second setting. DFSee prints both lines, one per setting.

The component (FAT and/or USB) of OS/2 may be outdated, because OS/2 may have to check or set both settings. Apparently Windows 7 checks both settings, and OS/2 sets one setting. DFSee checks and sets both.

If needed I can attach image files again, if one still wants to research the orginal wrong situation.

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #20 on: May 07, 2017, 02:38:23 pm »
FAT32.IFS beta, with and without the /FAT switch: "could not find address of LoadTranslateTable" (ZIP distribution, replacing existing install of an old version of FAT32).

Edited output of DFSee (works), setting A and B:

Quote
Executing: dirty clean               
                                                         
(A) FAT boot record successfully updated with new DIRTY status
(B) FAT areas successfully updated with new DIRTY status     
                                                         
FAT DIRTY status  : 0x00 = CLEAN

Valery Sedletski

  • Jr. Member
  • **
  • Thank You
  • -Given: 0
  • -Receive: 11
  • Posts: 73
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #21 on: May 08, 2017, 07:39:42 pm »
2Andre Heldoorn: What program writes that message? Which version? Do you have U*.DLL on LIBPATH? Are there older UFAT32.DLL on the LIBPATH? Did you unpacked all correctly?

PS: the required directory structure is preserved in the .ZIP archive.

PPS:
> What program writes that message?

Ah, I see, it is cachef32.exe. It cannot find LoadTranslateTable function in UFAT32.DLL. So, either, or no U*.DLL on LIBPATH, or an older version of UFAT32.DLL is used. Please clean up your LIBPATH from dups. eCS usually puts UFAT32.DLL in \ecs\dll, and I usually put it in \os2\dll. So, it should be only one newer copy.
« Last Edit: May 08, 2017, 10:05:40 pm by Valery Sedletski »

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #22 on: May 10, 2017, 06:06:16 pm »
Please clean up your LIBPATH from dups

Spot on, there was a second and older UFAT32.DLL in use.

Tested with FAT32. As expected, the latest version of FAT32 gets it right too, if the documented /FAT switch of FAT32.IFS is in use. No more CHKDSK dialog windows of Win7 after the FAT device, possibly including traces of VFAT data, was touched by OS/2.

Richard Crowley

  • Newbie
  • *
  • Thank You
  • -Given: 17
  • -Receive: 1
  • Posts: 44
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #23 on: May 18, 2017, 05:01:14 pm »
tried disk manager (Settings)?
 You can create/maintain or shrink FAT32 partitions that are readable on other systems (and assign a MBR and drive letter). Sometimes free progs like paragon free commander can work somewhat well on a volume as you describe. Sometimes I usedc a combination of tools. disk management performs many of the functions that we formally used fdisk and sfdisk for.

André Heldoorn

  • Full Member
  • ***
  • Thank You
  • -Given: 37
  • -Receive: 8
  • Posts: 235
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #24 on: May 19, 2017, 02:51:57 am »
tried disk manager (Settings)?
 You can create/maintain or shrink FAT32 partitions that are readable on other systems (and assign a MBR and drive letter).

In this specific case eCS doesn't support my FAT32 USB devices, due to at least one of the many poissible reasons why. Hence the use of classic, older FAT USB devices. A small, common shared FAT32 partition is an option too, but as such I'm not looking for a permanent shared device and the quality of my life actually will have been improved when I don't have to transfer files from Windows to OS/2 anymore (while remaining an user of OS/2). So FAT32 does look good, with its /FAT switch.