Is Windows BOGUS as a copy "tool"?

[Nesa]

Somehow, one of my very important 468.368 bytes txt file is partially corrupted when opening with some programs but not corrupted when opening with Winhex.

When opening it with Notepad or Wordpad or Firefox... the first 32768 bytes has unexpected content and the rest of the file is good. Those 32768 bytes (64 sectors) are picked up from a different part of hdd and the rest is picked up from the right place.

But, when opening it in Winhex the content of the first 32768 bytes are god (the rest also good).

When I make a copy with Commander or My Computer I get bad copy (first 32768 bytes wrong, the rest is good) but when make a copy with WinHex or TestDisk I get a good copy (right content) of “corrupted” txt file and later it can be wieved in Notepad or Wordpad...

So, I have some questions:

- WHAT IS THE REASON FOR THIS DIFFERENCE
- does it mean that is unsafe to backup data without WinHex/TestDisk or some other similar direct access tool because the backuped data may be corrupted because of some BUG when Windows operate with files
- does it mean that Windows Copy command is partially BOGUS and Windows as a “copy tool" also
- does it mean that backup made with Windows may NOT be IDENTICAL with original as it should be and there is no warning about it

P.S.

I use XP SP2

Attachments

[HaQue]

Sounds like your FAT/NTFS is corrupt. When you do a checkdsk or scandisk, these sort of errors are picked up. Different software handles funky things differently.

If you can, I would take a disk image, and then maybe a scandisk..

[Nesa]

Thanks.

I don't remember that checkdsk or scandisk were used. It's NTFS.

Is there any LOG file when checkdsk or scandisk make "repair"? Is it possible to revert this changes? What about $LogFile? Does it contain usable info which can be used for reverting?

[HaQue]

I meant that chkdsk or scandisk would probably find the errors, broken chains, or errors in the records. If you can make sure you have saved your data, then do a scandisk. Is SMART ok on the HDD?

It is possible there is a character or byte in the file notepad doesn't like, an error on the HDD or something like that.

What happens if you save that file(a good copy) on a thumb drive and view it in notepad on another PC.

There are no bugs as you describe with windows copy that I am aware of.. if win has an issue it usually pops a msgbox about it.

If the file is not secret/personal, maybe we/I could check it out?

cheers

PS, anytime ANYTHING strange starts happening with your DATA... make doubly sure your backups are good.

[Nesa]

I meant that chkdsk or scandisk would probably find the errors, broken chains, or errors in the records. If you can make sure you have saved your data, then do a scandisk. Is SMART ok on the HDD?

SMART and hdd are OK. No problems at all.

It is possible there is a character or byte in the file notepad doesn't like, an error on the HDD or something like that.

It is irrelevant which program is opening txt file (Notepad, Wordpad, any txt viewer). It does not opet complete file (468.368 bytes). It reads first part (64 sectors) from LBA 81.264.643 instead of LBA 81.322.562 where 32.768 bytes of REALL txt file are stored.

What happens if you save that file(a good copy) on a thumb drive and view it in notepad on another PC.

Same! A good copy with the partially wrong content is same on any PC.

There are no bugs as you describe with windows copy that I am aware of.. if win has an issue it usually pops a msgbox about it.

Actually, the problem is in DIFFERENCE in reading from hdd between WinHex/TestDisk (direct access) and by Windows My Computer. Same thing happened when tried to view file in Commander with View command (F3).

So, my question is WHY different tools show DIFFERENT results of GOOD file. What is the cause? Where from they read stored file's data (location, lenght...) Is it from $MFT or not and how is possible to have not the same results when reading that txt file content.

Considering that I do not know anything about it, if anyone can recommend a link on the subject.

BTW, few hours later everything is OK and the PC was the whole time on. But, I am still interested in answer.

P.S.

Here is the good table pic

Attachments

[fzabkar]

Could Windows have been reading a cached copy of the file in virtual memory???

[Nesa]

Could Windows have been reading a cached copy of the file in virtual memory???

And what about Commander? Same thing happened when tried to view file with the View command (F3).

[fzabkar]

I once had a problem on a Windows 98SE system with two JPEG files. If I copied these JPEGs to a 2GB flash drive, they would appear to copy correctly with the same size as the source files. However, when I tried to view them on a different Win98SE system, they were corrupt. This corruption was at the end of the files.

Copying the same files from the original HDD to a different location on the same HDD was OK. Both the original files and their copies displayed correctly. If I renamed the corrupt files on the flash drive and copied the original files from the HDD to the flash drive a second time, the same files were once again corrupt. I did finally manage to transfer the files, but only by ZIP-ing them.

The file system was FAT32 on both HDDs and the flash drive.

BTW, I successfully copied other similar JPEGs of similar size in the same folder to the flash drive.

[Nesa]

Very interesting behaviour!