Copying files with a simple renamer preset does not work.
The \\ from the network drive is only translatet to a single \ and therefore the file will be copied to drive C:
See the attached screenshot
Win11 Version 2025.2.4
I see what you mean.
I have a Renamer preset to copy to a network drive and it shows the same result - replaces the leading \ with C: I ran it and confirm that it created a new folder on my C: drive - the preview simulation reflects reality.
I have used this preset successfully in the past but not for many months so I have no idea when it was affected. I am on the latest IMatch and Windows 11.
Michael
This was caused by a "safety" feature. I have no real idea anymore why I made the Renamer replace \\ with \.
The comment in the copy/move step in the code is
"In case the user does something stupid, replace double backslashes".
And the code is unchanged since the initial commit of the code in git, in February 2018.
I have removed the stupidity protection and it of course works now as it should.
Work-around until the next IMatch release comes out: Use a drive mapping for the UNC share.
I have a a Renamer a preset that I use all the time, which moves files to a target UNC Path, and it has always worked. I'm pretty sure that the last time I used it was under the latest IMatch release, and it still worked...(i.e. it did not replace \\Name with C:\Name).
Unfortunately, I will not be where I can test this again until late tomorrow. I'll report back either way.
That's strange. When stepping through the code in the debugger, I can see that \\ is replaced with \, which makes the copy\move fail. Removing the code makes it work. And this code is unchanged since 2018, I can see every change I made since then in my version control system.
Let me know what you find out, and which UNC share you use.
I am still not where I can perform the test, but I have confirmed that I successfully ran the Renamer Preset just three days ago for a batch of a few hundred files. The History for one of them shows the target UNC Path:
Screenshot 2025-03-23 093104.png
And the Preset, when opened for a currently local file, also shows the correct (currently unavailable) target path for the Destination File:
Screenshot 2025-03-23 093030.png
Perhaps because I'm doing a Move and not a Copy (as is being discussed here), it's a different execution path?
When I get home tonight, I'll run the Preset on a file, with Debug Logging on, in case it can help identify the difference in my case.
It affected both Copy and Move.
You need to click on Preview in Renamer and check the Copy/Move column. The Destinantion file is always correct and not affected.
Here is what the Preview shows here (the leading \\ in the UNC path is retained):
Screenshot 2025-03-23 161844.png
It's in the
Edit Dialog for that
Move step, where I see the \\ replaced with \:
Screenshot 2025-03-23 162048.png
...but that's not happening for me at runtime.
Also, the
Preview in the ScreenShot from the OP has four columns (which translate to):
- Result
- Original Name
- Target Name
- Copy Name
...but mine has only three:
- Result
- Original Name
- Resulting Name
Is that a difference between a Copy and Move step?
Thanks, Tony
I have fixed the glitch (same reason) in the Copy/Move dialog.
Since you move the file, you get one column less.
Not sure why this does work for you with the \\, but it now works here in all cases, and that's good enough for me right now. Busy times. Thanks for checking.