[TC11.51] Copy "Only file of this type" inconsistently leaves selection

[white]

I have these files and folders:
d:\1\dest1\
d:\1\dest1\dest2\
d:\1\1.pdf
d:\1\2.txt

In the left panel, I go to d:\1\dest1
In the right panel, I go to d:\1
In the right panel I select the 2 files
I press F5, Tab, and I type *.pdf and press Enter
result: 1 files is copied and no files remain selected

In the left panel, I go to d:\1\dest1\dest2
In the right panel I select the 2 files
I press F5, Tab, and I type *.pdf and press Enter
result: 1 files is copied and 1 file remains selected

I get this result often, but not always. It seems to be a timing issue.

[ghisler(Author)]

Not a bug.
What happens in case 1 is that the date/time of the dest1 subdirectory is changed by Windows. This causes a full refresh in TC (because dest1 is a subdirectory of the source directory), removing the selection.
In case 2, the target path isn't a subdirectory of the source directory, so nothing changes in the source. TC has removed the selection of the files which were copied, so the selection of those which were not copied remains.

[white]

Yeah, no.. As I said, it's not consistent. I also sometimes get the refresh when copying to folder d:\2, which obviously is no subfolder of d:\1.

How is it supposed to work anyway? Only copied files are unmarked? And only folders that are copied are unmarked regardless of whether their contents is copied? Shouldn't it documented?

I would find it logical if all files/folders get unmarked when they are processed, either when they are copied, or when they are skipped due to a specified file type filter. So if a copy operation has ended, no file/folders should be left selected, unless the copy operation was aborted half way.

[ghisler(Author)]

Normally when you copy files, those which are copied will be unmarked. After the operation, the not copied files stay marked, unless the source directory was changed - then a full refresh is performed.

[white]

Normally when you copy files, those which are copied will be unmarked. After the operation, the not copied files stay marked, unless the source directory was changed - then a full refresh is performed.

Not quite. When the target folder is on another drive, the behavior is consistent. But when the target folder is on the same drive, the result is inconsistent. Copying the same source files to the same target folder behaves sometimes one way, sometimes the other way. And this apparent inconsistent refresh issue isn't limited to cases where the target is a subfolder of the source folder. For example, it also happens when copying from folder d:\1 to folder d:\2.

The selection behavior also feels unintuitive. When copying without a filter, Total Commander unselects all files and folders processed as intended (those successfully copied). Items remain selected only if error(s) occurred and the operation was aborted, clearly signaling something unintended happened.

With a filter however, the logic shifts. Even when the copy operation matches the user's intent, some items stay selected. Files excluded by the filter (e.g., 2.txt with a *.pdf filter) remain selected, suggesting they're pending while they were deliberately skipped. Folders, on the other hand, are unselected even if no files inside are copied (like a folder "docs" containing only file2.txt, which creates an empty "docs" in the target yet gets unselected).

To me, intuitive behavior would unselect all items processed as intended (whether copied or skipped by the filter), leaving only items selected that were meant to be copied but weren't. The current behavior feels inconsistent and unintuitive, and should be documented if it remains unchanged.

[ghisler(Author)]

But when the target folder is on the same drive, the result is inconsistent.

As I have described above, the full refresh happens when something in the source folder changes. In your case, the target folder is a subfolder of the source folder, and Windows changes its date/time when you copy to it.

[white]

But when the target folder is on the same drive, the result is inconsistent.

As I have described above, the full refresh happens when something in the source folder changes. In your case, the target folder is a subfolder of the source folder, and Windows changes its date/time when you copy to it.

As I described above, I have also tried cases where the target folder is NOT a subfolder of the source folder.
And I described that it doesn't happen consistently, while doing exactly the same copy operation.

[white]

See this video.

The video shows:
The target folder (d:\3\ at the left) is not a subfolder of the source folder (d:\1b\ at the right).
2 files are selected: 1.pdf and 2.txt
The files are copied with filter *.pdf
1.pdf is copied, no files remain selected.
1.pdf is deleted.
2 files are selected: 1.pdf and 2.txt
The files are copied with filter *.pdf
1.pdf is copied, 1 file remains selected.

[ghisler(Author)]

I have tried to reproduce this with the exact same names, and found that when I copied the first file (pdf), the file time of the parent directory [..] on the right panel changed, causing the refresh. This happens sometimes when the date/time of the target directory ("3") changes, and the date/time of the partent changes too. I only saw this because I was using a date/time format showing the seconds.

So the explanation I gave above still stands: The source directory is reloaded when anything in the source panel changes (in this case the time of the parent directory).

Try this:
1. Delete everything from the left directory '3', including all subdirs.
2. Create a new subdirectory in the left directory '3'.
3. Press Ctrl+R (refresh) in the right panel -> The date/time of [..] changes

[white]

I have tried to reproduce this with the exact same names, and found that when I copied the first file (pdf), the file time of the parent directory [..] on the right panel changed, causing the refresh. This happens sometimes when the date/time of the target directory ("3") changes, and the date/time of the partent changes too. I only saw this because I was using a date/time format showing the seconds.

So the explanation I gave above still stands: The source directory is reloaded when anything in the source panel changes (in this case the time of the parent directory).

I understand now. The parent folder's ("..") timestamp didn't change due to the copy operation; it was already outdated before the copy. After the copy, TC checks for outdated entries and catches this.

This issue is not limited to this situation only, and you cannot expect users to understand why TC seemingly behaves inconsistently. For example, suppose a user spends hours selecting files in D:\source, which has many files. He wants to copy these to some folder in d:\project. In the other panel, he navigates to d:\project, creates a new folder there called "Project X", and enters it. Then, he goes back to the panel with the selected files to copy them. He accidentally presses the Windows key, causing the Windows start menu to pop up. He presses the Windows key again to close the Windows start menu and return to Total Commander. Now, TC refreshes the folder contents and removes the selection of the files the user took hours to select. It’s unreasonable to expect the user to realize that creating a folder in d:\project, caused TC to update d:\treeinfo.wc, which caused that the ".." entry in d:\source was out-of-date, which caused the loss of the selection when TC temporarily lost focus.

Something similar can occur when working on drive C:, when a Windows process writes a file to the root.

On FAT file systems, the ".." entry is a real entry with a fixed timestamp, unchanged by parent folder updates. So this issue does not occur on FAT drives and wasn't a problem in the past. On NTFS, ".." is a virtual entry reflecting the parent’s dynamic timestamp, so TC effectively checks both the folder and its parent for changes.

A possible solution is to make sure the ".." entry is always updated but ignored when creating a checksum of the file attributes, to avoid triggering a refresh. (Technically: Check the ".." entry separately and update it right away. Create the checksum without the ".." entry.)

[AntonyD]

2white
Very sobering reasoning and an excellent suggestion. We hope it will be done just that.
Thank you for diving into this problem....
I have this loss of file selection very often.
I'm just used to swearing to myself and starting to retrace all the steps all over again.....

[ghisler(Author)]

A possible solution is to make sure the ".." entry is always updated but ignored when creating a checksum of the file attributes, to avoid triggering a refresh.

That's a great idea, I was able to implement this with very little overhead.