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

xynixme

  • Guest
Avoiding Windows 7's CHKDSK?
« on: May 01, 2017, 11:31:46 pm »
A 256 MB flash drive (FAT) is sometimes used to transfer files from Microsoft's %*!*&#$ 7 (NTFS) to eCS (HPFS), using CMD.EXE. After the transfer the files are deleted, with CMD.EXE (DEL or RM).

If this empty USB flash drive is used again by %*!*&#$ 7, then %*!*&#$ 7 always claims that the drive may be damaged and it has to be checked. The check never repairs anything. Is there a way, for example by using a DFSee command, to stop %*!*&#$ 7 from believing that aliens have touched the drive?

The CHKDK procedure doesn't last that long, but the useless dialogs are annoying. Aliens haven't invaded the drive, and it's always okay. Protection or prevention plays no role.

Mathias

  • Full Member
  • ***
  • Posts: 196
  • Karma: +2/-0
  • using ArcaOS
    • View Profile
    • IRC
Re: Avoiding Windows 7's CHKDSK?
« Reply #1 on: May 02, 2017, 12:19:11 pm »
Did you properly umount the flash drive after using it, or did you just remove it?

Win usually caches data when stuff gets transferred. This can be set up in the properties of the drive in hardware manager. On or off.
The default is ON, so you always need to properly umount the drive before removing it.

Running chkdsk with parameter /F should clear up the mess for now. Then properly umount the drive, wait some seconds and connect it again. Things should be fine now.

drjohnnyfever

  • Guest
Re: Avoiding Windows 7's CHKDSK?
« Reply #2 on: May 03, 2017, 02:17:43 am »
Windows 7 and newer are supposed to not write cache removable drives by default allowing for "quick removal" but I have had the same thing happen to me multiple times even after deliberately un-mounting.

No corruption is ever found, same as you. I wonder if eCS is somehow marking FAT as dirty inadvertently.

Andy Willis

  • Sr. Member
  • ****
  • Posts: 292
  • Karma: +7/-0
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #3 on: May 03, 2017, 03:13:59 am »
On OS/2, if you have cache enabled for a filesystem it includes for the USB drives.  If they are not properly ejected on OS/2 they will be marked dirty.  If you plug it back into an OS/2 system does it say it is dirty?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #4 on: May 03, 2017, 05:02:01 am »
Wonder if something about the EA's are confusing Windows. NT does/did support OS/2 EA's on FAT, I've even seen W2K chkdsk fix them. I wouldn't be surprised if something has changed in Windows FAT support and they never even tested with OS/2 EA's. It's awkward as both OS/2 and Windows uses some reserved bytes for different purposes, pointing at EA's with OS/2 and supporting (pointing at) long file names on Windows

xynixme

  • Guest
Re: Avoiding Windows 7's CHKDSK?
« Reply #5 on: May 03, 2017, 03:44:36 pm »
Did you properly umount the flash drive after using it, or did you just remove it?

The normal dirty-bit shouldn't be set. W7 accepts the drive, a FAT-named ZIP file (which contains *.DOCs, to be mailed with eCS) is moved to the USB flash drive (Ctrl-X, Ctrl-V), the drive is ejected properly. Of course "ejected properly" always includes waiting for darkness, without flashing LEDs.

eCS accepts the drive, and CMD.EXE is used to copy the ZIP file to a local drive and to delete the USB flash drive's files (DEL *). The drive is ejected properly, so eCS would be able to access it next time without requiring a CHKDSK.

It this USB flash drive is used by Win7 again, then Win7 wants to execute its CHKDSK dialog. As if the drive was touched by an alien. So far 100% of the Win7 CHKDSKs were 100% useless.

I do prefer a quick OS/2 solution above working with Win7, but IIRC it's possible to disable Win7's option to not having to eject the drive properly. So, assuming a default Win7 setup, is Win7 perhaps "confused" because eCS has no such option and cannot set some new, Microsoft-specific clean-bit?

xynixme

  • Guest
Re: Avoiding Windows 7's CHKDSK?
« Reply #6 on: May 03, 2017, 03:55:18 pm »
Wonder if something about the EA's are confusing Windows.

It's awkward as both OS/2 and Windows uses some reserved bytes for different purposes, pointing at EA's with OS/2 and supporting (pointing at) long file names on Windows

The WPS isn't used while working with the drive, other than to refresh removable drives XOR to eject the drive, FWIW.

Perhaps such a byte is used for a new "feature" of Win7 indeed, like not having to eject drives properly anymore. I don't know when which new Win7 "feature" was introduced, but apparently it doesn't bother OS/2 while Win7 detects a possible error.

The CHKDSK doesn't last long. Less than a second. Nevertheless a habit of answering "yes" may be dangerous if the next drive is a HPFS formatted drive and the question is related to formatting, by Win7, instead of the expected checking...

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #7 on: May 03, 2017, 04:05:58 pm »
Quote
Of course "ejected properly" always includes waiting for darkness, without flashing LEDs.
For me proper eject means either -
- in the drives object right click and Eject and waiting until the drive letter disappers
- or from command line eject x: and waiting until the prompt reappears what indicates the drive was properly ejected

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #8 on: May 03, 2017, 04:41:16 pm »
Maybe a stupid question but have you tried another USB stick? 

We use USB sticks from 1GB to 32 GB in size for transferring files to/from a couple of win 7 machines that a client uses and have never see any problems.  They were all setup using DFSee to provide the LVM information and drive letter and also do the FAT32 formatting.

There is also another possibility.  Depending on the age and amount of use your stick might be suffering from dead cells that the wear levelling isn't fixing.  While the OS/2, eCS FAT driver will generally ignore them win 7 will pick them up and report that it needs to run chkdsk which may not do anything if the dead cells are beyond what the wear levelling firmware can deal with (this is like the bad sector reports for floppy disks but because it is a flash drive it doesn't work the same as the floppy).

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #9 on: May 03, 2017, 05:16:31 pm »
Hi

Is this a case of Win7 "remembering" that it wrote files to the drive but they are not there now?

Try deleting the files the next time the drive is inserted into Win7 rather than when using OS/2 to see what happens.


Regards

Pete

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #10 on: May 03, 2017, 07:32:50 pm »
I haven't been following this thread, but win 10 will do something like that, if it is set for "fast startup" (or something like that, and it usually starts up slower anyway). What it does, is put win 10 to sleep, rather than properly shut it down. That means that the directory data is kept in sleeping memory (stored to disk), rather than getting written to the stick. When you start win 10 again, it loads the old data back into memory, and uses it. I wouldn't be surprised if win 7 (8 and 8.1)has something similar. Win 10 insists on turning the feature back on, without being asked, every once in a while. With win 7, you would need to enable it. In win 10, it is in the power control settings.

FWIW, if you share a system between win 10 and win 7, they will royally screw each other, if either one has the feature turned on.

Olafur Gunnlaugsson

  • Full Member
  • ***
  • Posts: 244
  • Karma: +5/-0
    • View Profile
Re: Avoiding Windows 7's CHKDSK?
« Reply #11 on: May 04, 2017, 02:33:40 am »
I haven't been following this thread, but win 10 will do something like that, if it is set for "fast startup" (or something like that, and it usually starts up slower anyway). What it does, is put win 10 to sleep, rather than properly shut it down. That means that the directory data is kept in sleeping memory (stored to disk), rather than getting written to the stick. When you start win 10 again, it loads the old data back into memory, and uses it. I wouldn't be surprised if win 7 (8 and 8.1)has something similar.

Win 10 and 8.1 do it by default, 8.0 if it is set for fast boot which most systems are but 7 does not have the fast boot feature at all.

xynixme

  • Guest
Re: Avoiding Windows 7's CHKDSK?
« Reply #12 on: May 05, 2017, 11:20:18 am »
Maybe a stupid question but have you tried another USB stick? 

We use USB sticks from 1GB to 32 GB in size for transferring files to/from a couple of win 7 machines that a client uses and have never see any problems.  They were all setup using DFSee to provide the LVM information and drive letter and also do the FAT32 formatting.

It's a FAT USB stick, so with a limited capacity. Clients can be yet another reason to fix it, because you don't want to be known for returning or delivering "damaged" drives. FAT32 isn't always an option, for example when an old FAT MP3 player is used.

Two images of the drive have been shipped to dfsee.com by now, and both files (same size) were different. Don't expect anything, but let's hope that some command can set OS/2's vritual "NumberOfEAs" bit from 0 to Windows' virtual "IsFlushed"-bit to 1.

If the average user of Windows gets used to answering Yes/Okay when an OS/2-drive is used, then one day this user may format your HPFS backup drive instead of CHKDSK'ing a FAT file transfer drive.

I could use a FAT32 drive for a test, but I'm not sure that OS/2 can access my device, and your test is as good as mine.

To reproduce, obvious steps excluded, FAT is classic FAT (FAT16): Use Windows 7 to save a FAT file, e.g. INVOICES.ZIP. Remove the USB FAT drive "safely". Boot eCS, use CMD.EXE to both "COPY x:\INVOICES.ZIP y:\" and "DEL x:INVOICES.ZIP". Remove the drive, and (try to) repeat the first step.

Quote
your stick might be suffering from dead cells that the wear levelling isn't fixing.

I cannot exclude anything, albeit I can use another, different FAT drive for testing purposes. The "IsFlushed"-bit is just a story too. BTW, I couldn't use an internet example to set or unset Windows flushing the drive. Perhaps that doesn't work with FAT. I'm using whatever the default setting is, and I'm used to manual flushing anyway. There drive is as old as 256 MB USB flash drives, but isn't iused that frequently. The images were produced with an "empty" drive (which still may include dead cells).

I do hope it's something like the usual DIRTY-bit of a drive, hence the "IsFlushed"-story. If so, then a command can be used to set it right for victims of Microsoft again. You don't want a client complaining about a damaged drive and/or a possible virus after you've borrowed their drive.

xynixme

  • Guest
Re: Avoiding Windows 7's CHKDSK?
« Reply #13 on: May 05, 2017, 11:46:31 am »
Try deleting the files the next time the drive is inserted into Win7 rather than when using OS/2 to see what happens.

A slightly different, improved test shows that Win7 first had to find a driver (for a different FAT USB flash drive) before it displayed that the drive could be damaged. Additionally I skipped the CHKDSK, and it wasn't impossible to access the drive (didn't actually try that, but there was no fatal error).

The MP3 files of this FAT MP3 player were written by eCS 1.2, with a randomized order of a Rexx utility which first converts "Long Filename.MP3" to nnnnnnnn.MP3 and uses COPY.

I guess this also excludes dead cells, unless the same cells of two drives happened to be dead. So far my conclusion is that Windows 7 offers a(n useless) CHKDSK when an USB FAT flash drive was "touched" by OS/2.

xynixme

  • Guest
Re: Avoiding Windows 7's CHKDSK?
« Reply #14 on: May 05, 2017, 12:03:23 pm »
Quote
Of course "ejected properly" always includes waiting for darkness, without flashing LEDs.
For me proper eject means either -
- in the drives object right click and Eject and waiting until the drive letter disappers
- or from command line eject x: and waiting until the prompt reappears what indicates the drive was properly ejected

I assume that compiling a perfect definition of "properly" has no use here, but after any of your additions the drive itself may still be active. If its LEDs are anything to go by, of course. And USB 1.0 flash drives aren't that fast. There is no relevant problem, but in this case my procedure includes both (one of) yours and mine. Hence the quoted "includes".

Or, IOW: there's no CHKDSK suggested nor required if the same OS is used again. Theoretically ejecting wrongly was a possible cause, it's about the same CHKDSK procedure, but IRL ejecting is unrelated.

I know people whom are conditioned by Windows. They switch on their computer, to boot Windows to remove a USB flash drive safely...