Changing case of any letter during rename moves file to end of file list

This is new behavior that started with 12.7.3.
I can make any other change to a filename -- add or delete single characters, change the name entirely, run any preset -- and the filename retains its position in the file list. If I change the case of any letter, though, it moves the file to the end of the list. So 'abC.jpg' changed, eg, to 'aZC.jpg' or 'Cba.jpg' will retain its position in the list, but changed to 'aBc.jpg', it moves to the end.

It's kind of screwing with my workflow; is there way to stop it from doing this?

Are we talking about inline rename (e.g. F2 from the file display), or when using the rename dialog? The file display during or after renaming things? Or the preview display inside the rename dialog?

If it's the file display, what is it being sorted by? Name, or something else?

Could you show us a screenshot?

Is Preferences / File Operations / Copy Options / Sort newly created and copied files on or off?

Thanks for responding quickly.

I was talking about inline renaming, although I just checked and the same thing occurs if I rename a file using the dialog.

And then we're talking about the file display, after the rename has been committed (ie, I've hit enter in the inline or 'ok' within the dialog.)

This happens whatever the sort method -- name, size, modified et al. The behavior I'm used to is renamed files do not sort until I manually refresh the display.

The preference you mention is off.

Screenshots:
Files sorted by name:

Renamed file with completely new name, still in position, still selected:

Changed case of letter e; upon hitting enter, moves to end of file list and also deselects:

Is your Downloads folder a normal folder on the D: drive, or have you moved it to another drive?

Does this happen if you try the same thing in another folder (e.g. C:\Test)?

Downloads is a normal folder, yes. And yeah, it happens globally -- all file types, in all folders, across all drives (fixed, network, and removable).

ctestdtestktest

This looks like a Windows bug to us, but we may have a workaround for it, pending some more internal testing.


A little detail:

If you do a case-only rename, Windows reports that the file is deleted, and then that it has been renamed.

This happens in Windows 10 but not Windows 7, from some quick testing. Presumably this is something Microsoft did to fix a bug in something else which failed to notice case-only renames. If so, they fixed the bug in the wrong place and now the operating system reports incorrect events, creating new bugs in other places.


I'm not sure if the workaround will be part of Opus 12.8 as it may be cutting things a bit fine. It may depend on whether we do another beta before releasing 12.8. If not, it'll be part of the first beta after 12.8 goes out, assuming we don't find any problems from our own testing before then.

1 Like