'File not found' bug ... (TC 'forget' the extension part ?)

[Scythal]

Regarding this bug that has been there for years and which must be pretty hard to find because it only happens once in a while, it seems to be caused when TC forgets the file extension.

So you want to do something with a file (copy, delete, view) and TC says 'File not found' (or something similar), chances are it tries to process "<file>" instead of "<file>.<ext>".

I believe that because it just wiped out an entire project directory instead of "project.7z" which was an old temporary copy.

But I doubt this will ever be fixed, since TC's development has stopped?

[Horst.Epp]

That never happend and also TC developement is of course not stopped.
I classify such posts as trolling.

[HolgerK]

So you want to do something with a file (copy, delete, view) and TC says 'File not found' (or something similar), chances are it tries to process "<file>" instead of "<file>.<ext>".

Would be nice to tell us what action you exactly performed with Key strokes, Mouse (TC-Button) or Context Menu.

I believe that because it just wiped out an entire project directory instead of "project.7z" which was an old temporary copy.

You believe, but do you know?
Without any Delete Confirmation Dialog (strange as this can't be easily turned of in TC)?
Not content can be found in Recyle.bin?
Context Menu -> Restore Previous Versions?

But I doubt this will ever be fixed, since TC's development has stopped?

Last version of TC is from 2017-11-24.
Won't say that development is stopped.

Regards
Holger

[Scythal]

That never happend and also TC developement is of course not stopped.
I classify such posts as trolling.

And most will classify such response as trolling. Simply because you never saw this problem (supposedly) doesn't mean it doesn't exist, just stating that it "never happend" (sic) doesn't make it true. Also, note the question mark, it was just a question but I suppose those little details fly right above your head.

Make sure to watch those typos.

So you want to do something with a file (copy, delete, view) and TC says 'File not found' (or something similar), chances are it tries to process "<file>" instead of "<file>.<ext>".

Would be nice to tell us what action you exactly performed with Key strokes, Mouse (TC-Button) or Context Menu.

I bring the cursor over a file (up/down and so on), and when it's over the file, I press the key for the desired operation. So delete, F5, F6, F8 for example. No mouse interaction

In this particular case, the cursor was brought to a <name>.7z compressed file, then shift-delete to remove it. And the <name> directory was deleted instead. No file was selected (marked in red with space bar or shift), it wasn't a mistake on my end.

I believe that because it just wiped out an entire project directory instead of "project.7z" which was an old temporary copy.

You believe, but do you know?

I don't have the sources, so I can't know, but the coincidence is worth mentioning.

Without any Delete Confirmation Dialog (strange as this can't be easily turned of in TC)?
Not content can be found in Recyle.bin?
Context Menu -> Restore Previous Versions?

Heh, nope. I usually shift-delete to avoid cluttering the recycle bin, but I wasn't expecting this to happen. And the confirmations were all disabled.

It's not a huge problem in itself, but this bug has been annoying me for years (without exaggerating), with several OSes, on several computers, so it's not just a corrupted program nor a one-time occurrence. It's just not easy to pinpoint because it happens about once in 2-3 months on average, and usually without consequence so I haven't reported it until now.

This time it was the latest TC version on Windows 7 Pro.

But I doubt this will ever be fixed, since TC's development has stopped?

Last version of TC is from 2017-11-24.
Won't say that development is stopped.

Regards
Holger

Well that's very good news! I saw "final" on the file name and indeed a "This is the final release!" announcement so I feared it was the end of it

[HolgerK]

I usually shift-delete to avoid cluttering the recycle bin, but I wasn't expecting this to happen

Restore previous version should be independent from shift+delete.

And the confirmations were all disabled.

This will not disable TC's delete confirmation, except:
You have disable the recylce bin confirmation? +
- you're are deleting files, folder inside a virtual folder like "//desktop"?
- or you've configured TC to use the explorer delete method?
- or you've manually set "VistaDelete=1" in wincmd.ini?

a "This is the final release!" announcement so I feared it was the end of it

Final release version after a long lasting series of beta test versions.

BTW: <Shift+del> is my preferred delete operation since many years and i never observed such a strange behavior, but i also live with confirmation dialogs and TC's own delete method.

I suggest to enable TC's Log function:
"Configuration->Settings... ->Operation:Log file ..."
Maybe this will give a hint what's going wrong if this would happen again.

Regards
Holger

[Dalai]

Do you work in the \\Desktop folder? If so, you should disable the option that hides file extensions in Folder Options (or Explorer Options), because if the option is enabled, the virtual folders hides the extensions, but TC always shows them.

If you already have this option disabled, then disregard my post.

Regards
Dalai

[Hacker]

Dalai,
While trying to copy files from my phone using the Alt-F1 - My Computer - Phone approach on a computer where showing file extensions was disabled in Explorer they were not shown in TC, either (so they could not be copied). I could imagine that it might be possible that it could somehow happen that if you select and delete a blabla.7z file in TC in a virtual folder where you don't see the file extension that blabla gets deleted instead, which would be quite... unfortunate.
Just a wild guess, though.

Roman

[Dalai]

2Hacker
Yes, you're right. I meant that TC always shows the extension in non-virtual folders/directories, but whether or not TC does so in virtual folders depends on the mentioned system setting. This could cause confusion (there are already a couple of threads about this), and maybe even processing of the wrong files, by the user or TC itself (just like you're guessing).

Regards
Dalai

[Scythal]

Restore previous version should be independent from shift+delete.

I didn't have a restore points nor a backup, no, those operations are performed too often to do that. Thanks for pointing that out though!

This will not disable TC's delete confirmation, except:
You have disable the recylce bin confirmation? +
- you're are deleting files, folder inside a virtual folder like "//desktop"?
- or you've configured TC to use the explorer delete method?
- or you've manually set "VistaDelete=1" in wincmd.ini?

Well spotted, I had to redo that on a test file to realize... I do confirm those deletes automatically, or almost! And this time the name shown on the confirmation pop-up was *almost* the same; I didn't expect this problem so I confirmed

I suggest to enable TC's Log function:
"Configuration->Settings... ->Operation:Log file ..."
Maybe this will give a hint what's going wrong if this would happen again.

That's a good suggestion, thanks! It could be a while, but at least it may capture helpful info next time.

you should disable the option that hides file extensions in Folder Options

Those are among the first ones I disable when installing the OS
No, when this problem occurs, the correct file is under the cursor without any ambiguity. The result of the operation so far had been a failure to find the specified file. And this time, it did the operation, but on the same filename without the extension.