[Fixed] Deleting a file on a network share disables...

[redfox]

Deleting a file on a network share temporary disables another file selection with left mouse.
It also disables a file opening/execution with a doubleclick.

1. Lets have a network share (another computer on LAN in a workgroup for example)
2. Open the remote share in one panel of TC
3. Select a file in there and delete it
4. You'll be unable to select another file in this panel anymore with left mouse (the line border above and under the row is gone), even execution a file with a doubleclick is impossible - left doubleclicks only highligt the file (for renaming) like normally repeated single clicks; a selection with right mouse is still possible
5. If you highligt the file (step 4) and rename it or leave it be and click another file, file selections and doubleclicks now work again in the shared directory.

The bug only occurs if you have Auto-Refresh enabled in the TC preferences.

It is never present on a local disk/partition, just on a shared one.

Win7/32

[ghisler(Author)]

Could you give me more details on '3', please? There are various ways to delete files in TC which use different functions:
1. Del or F8 key or button
2. Right click context menu - Delete
3. Special case of the above where recycle bin has been enabled for network drives

[redfox]

I just tried the new version 9b15:

Delete with:

Del - bug present
F8 - bug present
context menu - delete with mouse - bug NOT present

Recycle bin is not enabled for network drives.

[ghisler(Author)]

1. What about Shift+Del / Shift+F8?
2. Is this share an unc path, e.g. \\server\share, or does it have a drive letter, e.g. z:\ ?

[redfox]

1 Shift+del and shift+F8 = bug present
2 It's a workgroup computer without a drive letter

I have found something new:

If I get the bug and then switch from the network share to a local disk partition in the same TC panel, the selection/execution with left mouse is still not possible, until I rename a file a file or switch to the other TC panel and back.

[ghisler(Author)]

Sorry, still no luck in reproducing your problem.

Does anyone else have this problem?

[redfox]

Ghisler> Did you try it with a workgroup computer on a slower LAN, with a directory with a higher number of files?

EDIT: I just tried it with TC 8.5.1.1 and the bug is NOT present there (autorefresh enabled)

EDIT2: If I disable the Auto Refresh completely in TC 9 via GUI settings, the folder content (files count etc.) is updated anyway, after a change (delete a file for example), for both network AND local files. It seems you broke the autorefresh feature somehow.

What does the autorefresh do, if it works even if completely disabled? Does it refresh everything twice?

[ghisler(Author)]

I checked the functions, and I could indeed find a difference: The watch dir thread is running with lower priority in TC 8.x and older betas. I had increased the priority to normal when debugging, but didn't set it back to lower afterwards. I have changed that now in beta 16. Can you try it please?

[redfox]

ghisler> The bug still exists in 9.0b16.
As a workaround, I'll leave the autorefresh feature disabled.

[ghisler(Author)]

Sorry, I really can't see any other changes which could cause this. And I don't know of any way to test it if you can't let me test it on your system (e.g. via teamviewer or remote desktop), but your security will not allow that anyway. Therefore the problem will remain unresolved forever.

[redfox]

Not a big deal, thanks anyway. I only wonder, why the autorefresh still works, after I disable it in the settings.

[ghisler(Author)]

There are two types of auto-refresh, configured via Configuration - Options - Refresh:
1. The upper half refreshes dirs when you switch from any other program to Total Commander. Can be disabled by drive letter.
2. The lower half listens to Windows notifications when files are changed in the file system. This updates files even if they get changed while TC is in the foreground and not responsible for the change, e.g. files changed by other users.

Maybe there are 1000s of changes per minute on that share causing TC to get too many notifications? But then the same problem should also happen with TC 8.x...

[redfox]

The share is completely idle with only one user connected. A folder content is always visibly auto-refreshed after deleting a file. The delete process can take up to 3 seconds with a hourglass. Maybe some TC funtion times out after such long delay, which can cause the bug mentioned above.

After that (and autorefresh turned on), the separators (borders) around a file are not drawn and left doubleclick acts as two separate single click, which only leads to the file renaming.

If the delete process and folder refresh is a bit faster, the bug does not occur. It is a rare case on my network. The MS file sharing service is slow by design, I always have had problems with its reaction times, between different Windows versions.

[Graslama]

I tried reproducing this and had no success. i used a network-share wird more than 2000 old files, deleted a file and was able to do other operations after.

Maybe it has to do with the Symbols (icon) -settings in the TC-Options? maybe disabling "show symbols for network dir´s" can help?
Sometimes TC reacting slow on network-paths when it reads icons from the .exe and .lnk files. while the icons got read from TC you can´t do other things in TC. the cursor is lost while this, some seconds.....

maybe i riding the wrong horse but it´s a idea in an other direction *eg*

[redfox]

Bug still exists in TC v9 RC1, if the auto-refresh is enabled.