'Copy' via script chops off extension

[lxp]

This will work in 12.24:

function OnClick(clickData) {
    var cmd = clickData.func.command;
    cmd.deselect = false;

    cmd.ClearFiles();
    cmd.AddFile('D:\\FolderA\\image.jpg');
    cmd.RunCommand('Copy TO="D:\\FolderB"');
}

In 12.24.1, the extension will be missing: D:\FolderB\image.

<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" textcol="none">
	<label>New Button</label>
	<icon1>#newcommand</icon1>
	<function type="script">
		<instruction>@script JScript</instruction>
		<instruction>function OnClick(clickData) {</instruction>
		<instruction>    var cmd = clickData.func.command;</instruction>
		<instruction>    cmd.deselect = false;</instruction>
		<instruction />
		<instruction>    cmd.ClearFiles();</instruction>
		<instruction>    cmd.AddFile(&apos;D:\\FolderA\\image.jpg&apos;);</instruction>
		<instruction>    cmd.RunCommand(&apos;Copy TO=&quot;D:\\FolderB&quot;&apos;);</instruction>
		<instruction>}</instruction>
	</function>
</button>

[Leo]

I haven't been able to reproduce this in 12.24.1. The extension is staying with the file here.

Is the extension missing if you check the file in FolderB using a command prompt? I'm wondering if it's there but being hidden from display.

[lxp]

No, it's not hidden. I noticed it when copying pairs of images (raw+jpg) off my camera and ended up with files DSC123 / DSC123 (1) etc. Switched back and forth between the versions a couple of times when writing the test script. Text files are affected as well:

Happy to dig deeper, of course. What direction would you suggest?

[Leo]

That definitely looks wrong, I agree.

Is D:\ the camera itself, or is it an SD card or similar that's been mounted?

If you run this from a non-script button, does it work OK?

Copy "D:\FolderA\image.jpg" TO="D:\FolderB"

That should basically do the same as the script, and might tell us which direction to look in.

In terms of scripting, there's a change in the beta to how the scripting file (Item) objects are built with respect to their display_name property. That's the most suspicious change that might be involved, since it affects file names in some places.

Could you check what Opus thinks the item name parts are like this, from the source folder:

function OnClick(clickData)
{
	var files = clickData.func.sourcetab.files;
//	var files = clickData.func.command.files;

	for (var eSel = new Enumerator(files); !eSel.atEnd(); eSel.moveNext())
	{
		var i = eSel.item();
		DOpus.Output('Name: ' + i.name);
		DOpus.Output('DName: ' + i.display_name);
		DOpus.Output('Stem: ' + i.name_stem);
		DOpus.Output('StemM: ' + i.name_stem_m);
		DOpus.Output('Ext: ' + i.ext);
		DOpus.Output('ExtM: ' + i.ext_m);
		DOpus.Output('');
	}
}

Or run that loop on the files object in your original script, after calling AddFile on it.

I'll see if I can find any other changes that are likely to affect what's happening. It's strange that it's finding the files at all, if it thinks they don't have extensions, which is making me doubt my initial suspicion about which change might be causing it.

[lxp]

Did more testing... the good news: 12.24.1 works fine on my second PC

---

I think the problem is my Win10 installation. Although it's a fairly recent fresh setup, some programs refuse installation or updates. A couple of days ago, I started receiving this message on boot:

It's odd that 12.24 runs well on my jinxed system and that this installation problem affects only such a tiny part of Opus. I'd be fine to just go on with 12.24, do another Win10 clean install in the next days, and then give 12.24.1 another go.

Since so far nobody else seems to have this problem, I guess it's sensible to stop here, but if you think this might be relevant to Opus' development I am more than happy to run more tests.

---

The details: I uninstalled Opus completely. Strangely, uninstall didn't work on first attempt:

Did a fresh Opus install and worked with the factory config. The problems remain the same.

---

Is D:\ the camera itself, or is it an SD card or similar that's been mounted?

That is my work drive, an NTFS partition on the main SSD.

---

If you run this from a non-script button, does it work OK?

No. Shame on me for not testing this myself before.

But these work:

Copy "D:\FolderA\image.*" TO="D:\FolderB"
Copy "D:\FolderA\*.*" TO="D:\FolderB"

So does Copy in a lister with source and destination.

---

Could you check what Opus thinks the item name parts are like this, from the source folder:

Name: image.jpg
DName: image.jpg
Stem: image
StemM: image
Ext: .jpg
ExtM: .jpg

Name: text.txt
DName: text.txt
Stem: text
StemM: text
Ext: .txt
ExtM: .txt

[BuckyB]

Just wanted to let you know I've had the same thing happen to me. I needed to change a button I use because the file-extensions were being removed.

Old (worked up to v12.24)

@nofilenamequoting
@runonce:@set dirname={dlgstringS|Enter name of folder to move selection into|{file$|noext}}
Copy MOVE HERE FILE="{file$}" CREATEFOLDER="{$dirname}"

New (needed to make changes for v12.24 beta 1)

@nofilenamequoting
@runonce:@set dirname={dlgstringS|Enter name of folder to move selection into|{file$|noext}}
Copy MOVE HERE CREATEFOLDER="{$dirname}"

[Leo]

Thanks to both of you for the extra information.

I've reproduced it on one computer now, and it looks like whether or not it works comes down to whether or not File Explorer is configured to show file extensions (which has a knock-on effect on what some shell APIs return).

Should have a fix for this soon.

[BuckyB]

Thank you, Leo and lxp!

[Leo]

Here's a hotfix ahead of the next beta:

EDIT: Proper beta / installer available now: Directory Opus 12.24.2 (Beta)

Thanks again!

[lxp]

Now that fix was quick and works well