Manual rename of a file fails

Case 1.

I have Dopus open with a folder tree to the left with the contents of a folder showing in the lister on the right. I slow double click on a file name to edit the name and change the file name, then with the file name still being edited I click on another folder in the left hand folder tree. The focus leaves the edited file name to display the new folder.

When I return to the original folder the file I was renaming still has the original file name. If I click elsewhere (I.E. on another filename or a blank area) in the same window the file renaming succeeds.

Case 2.

I am copying (or moving) a large file using the "Copy" or "Move" button on the toolbar. I slow double click on a file that is not being copied or moved and type a new name for that file. Press "Enter" when I am finished and the file reverts to its original name. If I do this when I am not copying the rename succeeds.

I cannot reproduce either case so far, using Opus 10.5.1.2.

Are you seeing that on a normal, local NTFS harddrive or on another type of device?

Could you tell us how these two Preferences pages are configured, in case one of the settings is key to reproducing what you're seeing:

[ul][li]Preferences / File Operations / Inline Rename[/li]
[li]Preferences / File Operations / Options[/li][/ul]

Thanks!

[quote="leo"]I cannot reproduce either case so far, using Opus 10.5.1.2.
[/quote]

I am using Opus 10.5.1.0

In case one I mainly notice it when I am changing file names on a Samba share on a NAS running freeBSD with ZFS on a rather large storage system. Case two has been happening on my local NTFS file systems - However I did reproduce case one on my local file system (just to be sure what was happening) before I posted.

In case two the copy (or move) is going from the local file system (NTFS) over my Gigabit network to the large Samba filesystem I mentioned. The Samba filesystem is accessed by many devices on my network with no problems except as mentioned with case two and the problem does not happen on the Samba filesystem, it happens on the local NTFS filesystem.

[ul][]Preferences / File Operations / Inline Rename[/]
All boxes unticked
Default Selection Mode: Select filename stem

[]Preferences / File Operations / Options[/]
Selected (ticked):
Deselect files used in functions
Postpone file deselection until end of function
Detect external file changes on network drives
Re-upload Modified files:
Check for modifications when launched process exits
Ask before uploading
Not Selected (Unticked):
Use file checksum to detect modifications
[/ul]

From memory these are all the default settings. I do not recall changing anything in this section (although I have been wrong before)

Thank you

Thanks!

I've made my setup as similar as possible (except with a Windows server instead of Samba, but if it's happening in the local directory then that should not matter), but I still cannot get either case to happen.

Here's a video showing my testing, in case anything stands out as different to what you are doing:

OK tell me what I don't understand here.

In the first part of your video, you have a file called "An Image.bmp" You rename it "test rename.bmp" then click on the folder "test2".

Then you click back to the folder "test" and there is "An image.bmp" NOT "test rename.bmp"

That's exactly it! The rename fails with no error message or anything.

As for case two, I can see where you are not reproducing it and I think it may be something in my local setup doing it. I have jumbo frames turned on so as to get better speeds with large file copies and my local machine does become a little unresponsive during a copy.

Ah, okay, I misunderstood what was meant by case 1.

Where you said:

I thought this meant that, after starting the rename, changing folder, then changing back to the first folder, you then (without starting a second rename), clicked somewhere in the folder and that triggered the original rename to then take place. If that happened it would be a weird bug and very unpredictable behaviour.

But now I understand that you meant the rename took place if you clicked somewhere else instead of changing folders, rather than after changing folders.

That makes sense now. Changing folders while in the middle of an inline rename will cancel the rename, the same as pushing Esc would cancel it. Before changing folders, the rename should be 'committed' by pushing return, clicking the background or clicking another file. I suspect the behaviour is by design (e.g. in case the folder change is in reaction to something the user didn't initiate, like a folder being launched by another program or async script), but maybe it makes sense to change it for this case where you're clicking on the tree.

Sorry I wasn't clear. My first intuitive thought was, "I am clicking elsewhere on the screen after completing tying the new name. It should complete the rename.

What is the difference when you

[ul][]Click on the background[/]
[]Click on another file[/]
[]Click on another window/program[/]
[]Click on another folder[/][/ul]

Only the last one fails to rename the file.

The difference is the folder is changing underneath the operation, which cancels it. The operation is tied to a file display and closing the file display (usually) cancels the operation. In the three other cases, the folder loaded into the file display stays the same and only the active window changes.

If you close the window, the operation is also cancelled.

(Although if you close just the tab it is not cancelled, so there is some inconsistency here at the moment.)

If you go by the rule that you have to see the change to be sure it happens, you'll be safe. (And even where that isn't strictly required, it's worthwhile in case there is an error and the rename doesn't happen for other reasons.)