Editing a file between copy and confirmation to overwrite

[samot]

- I have a file a.txt and b.txt
- I have a.txt open in a editor in the background
- I try to copy a.txt to b.txt and get a message saying, that b.txt exists and if I want to overwrite / skip / rename / cancel ...
- I switch to the editor and change the file (remove some lines) and save the a.txt again (is now smaller)
- I switch back to TC and choose Overwrite
- TC copies a.txt to b.txt, but b.txt has now the origin (unedited) size of a.txt and have some Hex 00 at the end
- same problem, if I choose to rename to c.txt

There is no problem, if I add some lines to a.txt, only if the edited a.txt is smaller then the original one.

Suggested solution: reread the file size just before copying

best regards

Thomas

[ts4242]

- TC copies a.txt to b.txt, but b.txt has now the origin (unedited) size of a.txt and have some Hex 00 at the end
- same problem, if I choose to rename to c.txt

I cannot confirm this

I can only confirm that the file panel not updated to show the new size of the file a.txt

[samot]

I just tried it again (with 7.03 and Windows XP SP 2) and the bug occurs again.

Are you sure, that you have edited / saved a.txt while the Overwrite-Dialog in the TC was visible?

best regards

Thomas

[ghisler(Author)]

What copy method do you use in TC?

[samot]

I tried both F5 and Shift-F5.

In the configuration I have the standard methode enabled.

best regards

Thomas

[ts4242]

What copy method do you use in TC?

I can reproduce now but only when the two files are in different drive format (source is FAT and Target is NTFS)
I reproduced it as follows:
1. Start TC with fresh ini file. (to be sure there is not any setting in affect)
2. create a.txt in FAT volume and b.txt in NTFS volume
3. Delete some line from a.txt file and save changes while overwrite dialog is visible

after overwriting, b.txt is appended with 00 bytes
this occurs only when copying from FAT volume to NTFS volume but not occurs when copying from NTFS to FAT

[ts4242]

I tried both F5 and Shift-F5.

I can reproduce also when copying between NTFS volumes but not FAT as mention above

[ghisler(Author)]

I have checked this in a debugger now. First, I have to tell you that Total Commander does NOT copy a specific number of bytes - it simply calls ReadFile as many times as Windows returns data, until ReadFile returns an error or the read data size reported by ReadFile is smaller than the block size. So with a block size of 32768, TC calls ReadFile until ReadFile reports a returned data size of less than 32768 bytes.

The extra bytes come from the fact that TC sets the file size at the beginning of the copy operation, before writing any data to the file (via SetFilePointer and truncate). I now found a solution (calling truncate again when the copied data is less than the previously set size). I will include it in the next release.

[StatusQuo]

Confirmed, but only for the internal copy function (Win2k SP4 and XP SP2).
With CopyCompatDrives=* I don't get this problem
(compatibility mode for all drives, that I normally have set).

[Edit]: a little too late, but the above can be used as workaround in the meantime.

[ts4242]

Confirmed, but only for the internal copy function (Win2k SP4 and XP SP2).

This bug belong to the file system not OS, I'm using WinXP sp2 and it is occurs only in NTFS volume not FAT!!!

[StatusQuo]

2ts4242
Yes, maybe I shouldn't have removed the details from my post after seeing that the problem's source is found.
I got the same results as you (failure on FAT > NTFS and NTFS > NTFS) - on the mentioned OS's.

BTW, with CopyCompatDrives=* the file system makes no difference.

[ts4242]

BTW, with CopyCompatDrives=* the file system makes no difference.

Confirmed!

[StatusQuo]

Fixed / not reproducible anymore in 7.04.

[ghisler(Author)]

Thanks!