Bug: Corrupt files

[bjevers70]

I have a removeable USB 2 flash drive and I am getting corrupt files on it when they copied to the drive using TC. If I use Windows Explorer, the files are fine. One example is the Nvidia DVD decoder trial available here:

http://www.nvidia.com/object/dvd_decoder_1.00.67-trial.html

When I copy it to my flash drive and try to run it, it says the file is corrupt. If I do a file comparision with the original file on my hard drive TC finds 14 differences.

There have been many other files that have ended up corrupt after copying to the flash drive, this is just one reproducable example.

I am running Windows XP SP2 Pro, TC 6.50, and I am using a PQI Intellistick 2.0 1gb flash drive.

Thanks...Brian

[bjevers70]

I just enabled compatibility mode in the copy/delete options for my flash drive and it works now.

[ghisler(Author)]

When I copy it to my flash drive and try to run it, it says the file is corrupt.

That's a VERY bad sign, it means that WriteFile causes corruption. This means that you should NEVER open any files directly from the stick for editing, e.g. using Word, because otherwise you would also risk data loss...

[bjevers70]

When I copy it to my flash drive and try to run it, it says the file is corrupt.

That's a VERY bad sign, it means that WriteFile causes corruption. This means that you should NEVER open any files directly from the stick for editing, e.g. using Word, because otherwise you would also risk data loss...

So is WriteFile a Windows function?

[ghisler(Author)]

Yes, WriteFile is the ONLY documented Windows function to write randomly to files. Compatibility mode uses CopyFileEx.

[bjevers70]

Yes, WriteFile is the ONLY documented Windows function to write randomly to files. Compatibility mode uses CopyFileEx.

What would be the best way of getting Microsoft to look into this and hopefully fix it? I wonder why it only happens with a flash drive.

[Zerryk]

Yes, WriteFile is the ONLY documented Windows function to write randomly to files. Compatibility mode uses CopyFileEx.

Did you mean this behaviour, or something else?
http://dietmonday.com/windows/WinDoc/msdn/sdk/platforms/doc/sdk/win32/func/src/f92_21.htm
Applications must not read from nor write to the output buffer that a write operation is using until the write operation completes. Premature access of the output buffer may lead to corruption of the data written from that buffer.

[ghisler(Author)]

No, I didn't mean that. Total Commander doesn't use overlapped I/O, it uses blocking calls in a thread. Since the function calls are blocking until the data is written (at least to the cache), there is no danger at all of modifying the buffer.