>
> Hi/2.
>
> That's too bad.
>
> We should wait for another chance.
>
> KO Myung-Hun
>

KO the FM/2 development team has been looking at this issue. Here is
one of their posts.

Hi,

> >It isn't the drive is FAT16.
>> >>Does it happen for all IFS's?

> >No it only happens with the USB drive. The only report I saw where it
> >caused problems with a FAT32 drive was a USB drive also.

OK. That clarifies it somewhat. It appears to be USBMSD that is broken,
not some IFS.

> >The first try gave me a double listing of the
> >directory I copied but other wise worked. Rescan was fine delete
worked
> >fine. I could reproduce the double directory name only if it was the
> >first copy to any drive during a session (prior to the drive being
> >touched beyond initial scan) however it doesn't matter if verify is on
> >or off this appears to be an FM/2 problem.

This appears to be the case.

Back to our USBMSD issue. Can you replicate the problem from the command
line? Try the delete with

VERIFY ON

It would not surprise me if this is a timing error. The kernel/ifs is
trying to do the verify before the drive is ready for another operation.

If we do need workarounds, they can localized them somewhat with code like

apiret = DosDelete(...)
if (apiret == ERROR_GEN_FAILURE && fVerify && DriveIsRemovable(...)) {
// turn off verify
apiret = DosDelete(...)
// turn on verify
}

If the above, I am assuming that the delete step failed and not the verify
step. Is this the case?

Steven