getNewNameData extensions when renaming a folder

During this discussion I noticed that the properties of the getNewNameData object are sometimes incorrect.

Here is a little button to demonstrate the oddity (bug?):

@nodeselect 
Rename {file} TO {file}
// Rename {sourcepath} TO {file}
@script jscript 
function OnGetNewName(getNewNameData) {
    DOpus.Output('');
    DOpus.Output('newname: ' + getNewNameData.newname);
    DOpus.Output('newname_ext: ' + getNewNameData.newname_ext);
    DOpus.Output('newname_ext_m: ' + getNewNameData.newname_ext_m);
    DOpus.Output('newname_field: ' + getNewNameData.newname_field);
    DOpus.Output('newname_stem: ' + getNewNameData.newname_stem);
    DOpus.Output('newname_stem_m: ' + getNewNameData.newname_stem_m);
    DOpus.Output('oldname_field: ' + getNewNameData.oldname_field);
    DOpus.Output('');
}

These are the outputs with a file whatever.part1.txt selected:

Rename {file} TO {file}

newname: whatever.part1.txt
newname_ext: .txt
newname_ext_m: .txt
newname_field: whatever.part1.txt
newname_stem: whatever.part1
newname_stem_m: whatever.part1
oldname_field: 

Rename {sourcepath} TO {file}

newname: whatever.part1.txt
newname_ext: 
newname_ext_m: 
newname_field: whatever.part1.txt
newname_stem: whatever.part1.txt
newname_stem_m: whatever.part1.txt
oldname_field: 

oldname_field occasionally shows the filename of a previous rename command.

What do you think is wrong there?

One of your renames is working on a file, the other on a folder. Folders don't have file extensions, so the properties for splitting names fom extensions will behave differently with files and folders, which I think is all you're seeing.

Oldname_field is literally whatever is typed into the old name field in the renamr dialog, I believe.

Yes, the first Rename will change the parentfolder, the second one the selected file itself, but both Renames are based on the filename and newname is in both cases whatever.part1.txt. So I would in both cases expect newname_stem to be whatever.part1 and newname_ext to be .txt.

Have a look at the thread mentioned above where we needed to remove the extension manually (instead of using newname_stem). Doesn't that seem strange? Or is this an unintended/unwanted use of Rename? Frankly, I was (pleasantly) surprised when a few weeks ago I found out that a command like Rename {sourcepath} TO {file} works at all :slight_smile:

If you are renaming a folder, the name you are using is always a folder name, and will be treated as such. Opus is giving you the properties of the folder with the proposed name, and what it's doing is correct and by design.

The TO={file} argument is just supplying a new name for the thing which is being renamed. That name may have come from a file, but that detail is irrelevant; if the thing being renamed is folder then the name will be treated as a folder name.

It's the same as if you selected a folder, clicked Rename to rename it, then manually typed whatever.part1.txt into the new name field. It will use that as the folder's new name, and treat it as a folder name, even if it looks to us like something that would normally be a file's name.

In a script, you can create an item object for the file that the name is coming from: that will behave as you want/expect.

Yes... now I am getting it. Makes sense. Thanks!
I just knew it'd be better to not tag this as a bug report :wink:

1 Like