Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - André Heldoorn

Pages: 1 ... 43 44 [45] 46 47 ... 53
661
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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.

663
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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

664
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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.

665
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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.

666
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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...

667
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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.

668
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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.

669
A happy accident?

FPos is not relevant. It avoided the problem for a short while. I was able to install a few WPS objects and to rename a WPS object. The problem is still there, because after a while ChckINI-messages like "handle <xxxx> (My object) already points to another object, My Object" start popping up again.

With CleanINI a few desktop directory-handles are removed (of existing objects, may be a clue?), and it deletes an impressive number of other handles too. Unfortunately default icons change to a blank icon or to some pointer icon, even after multilple WPS resets, so there still is a problem.

I guess it may be too specific by now, unless the changing default icons are a clue too. CheckINI reports no error then, but I'm afraid that's an accident waiting to happen. I'll consider a re-install. ;(

670
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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...

671
Applications / Re: Avoiding Windows 7's CHKDSK?
« 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?

672
Applications / 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.

673
Programming / ArcaOS
« on: May 01, 2017, 01:54:58 pm »
Is there a list of "fixes" since eCS 1.x? After all OS/2, eCS and ArcaOS are different products.

An example is an eCS 2.x programmer assuming that *.MP3 works like *MP3, if there is a file extension (as long as a filename ends with *.MP3, regardless of the number of dots). Apparently that was an eCS 2.1 "fix", which breaks compatibility with older versions of about the same OS, and eCS 2 nor ArcaOS are GA for more than 1 or 2 languages.

So, is there list of generic non-GA "fixes" (changes) since eCS 1.2? Since eCS 2.x? Of course "fixes" have to be relevant for programming and for all users, so a fixed driver for a "Splectaturn 2000", documented new APIs, yet another installed utility, or a new look won't qualify.

674
A happy accident? I may have solved the severe problem by using FPos (solving), or I created enough space with FPos to be able install a few new WPS objects without corrupting the WPS (avoiding). I deleted a few lines and I deleted a few records with an "Unknown" View.

The <Alt-F1> facility with 3 copies is a component of my backup procedures, but the 3 copies may contain an undetected corruption. If a backup wasn't clean, then there's the risk that the last uncorrupted backup cannot be found in the top-3 anymore. I'll look at solutions, and I'll look at a better procedure. Restoring an old boot drive copy remains a PITA, but it's better than starting from scratch again. At the moment I can still test the utilities with a broken backup.

WPTools' CHECKINI always detected the error(s), but then it's too late. CHECKINI or the OS cannot find the desktop, object A is a duplicate of object A, settings of "random" WPProgram will be erased, and so on.

675
Is there an utility which can repair damaged OS2*.INI files?

This time CHECKINI is not the answer. If there's one problem, then CHECKINI often tries to solve all derived issues. If INDEX.1 points to INDEX.2, INDEX.2 points to INDEX.3, and so on, but INDEX.1 may be missing, then CHECKINI may delete INDEX.3, index.4, and so on. What I want is that INDEX.1 points to INDEX.3. This is not the real problem, but it shows what I don't want.

In reality the desktop can be missing, settings will be lost, and so on, so I guess handles may be corrupted. Any change, like installing a new WPS object, corrupts the setup. CHECKINI and/or a restore a required frequently, for example after deleting a file. So is there a better INI file tool than CHECKINI. I can delete almost all objects, but of course that's a PITA.

Pages: 1 ... 43 44 [45] 46 47 ... 53