Forum

Please or Register to create posts and topics.

xcopy invocations should have the source not ending with backslash (for example ventoy install/upgrade fails)

I don't know what triggers this issue, but on my win10 ltsc 2019 laptop, xcopy failed to copy the ventoy files to usb drive with these messages:
File not found - F:\GRUB\GRUB.CFG
WARNING: F:\ventoy\core.img is missing from USB drive!

if you try to run the xcopy manually, you get:

F:\e2b\Update agFM>xcopy "C:\Users\ADMINI~1\AppData\Local\Temp\ventoy\" F:\ /q /h /e /r /k /y
Invalid path
0 File(s) copied

if I try to copy using powershell's copy-item command or robocopy, it works.

if you hit this issue, copy it manually like this:
edit Add_Ventoy.cmd in E2B_PTN2:\e2b\Update agFM
find xcopy
insert a pause and echo command before:

echo "%vtmp%\" %PTN2%\
pause

re-run the Update_to_latest_Ventoy_version.cmd
when script pauses,  copy the source and destination from echo output then open a cmd
inside it, run:
robocopy <source and dest you copied> /E
example:
robocopy "C:\Users\ADMINI~1\AppData\Local\Temp\ventoy" f:\ /E
then continue running the upgrade script.

Steve, perhaps can you adapt the script to detect such xcopy failure and retry with robocopy? wikipedia says robocopy is integrated into os since 2008 and is intended to obsolete xcopy.

I've tried procmon.exe on it, couldn't find anything. it just fails on me and I am giving up investigating why.

Is your C: drive a compressed NTFS drive?

What happens if you add *.*

e.g.

xcopy "C:\Users\ADMINI~1\AppData\Local\Temp\ventoy\*.*" F:\ /q /h /e /r /k /y

no it's not compressed.

at least one another report was filed in 2021, the same issue I presume:

https://rmprepusb.blogspot.com/2021/10/ventoy-for-easy2boot-v1057-available.html?showComment=1636134177986#c8532130687157067833

it does work if I add *.*

981 File(s) copied

also, it works if I strip the backslash at the end of source

C:\Users\V\Downloads>xcopy "C:\Users\V\AppData\Local\Temp\ventoy\" c:\temp\ /q /h /e /r /k /y
Invalid path
0 File(s) copied

C:\Users\V\Downloads>xcopy "C:\Users\V\AppData\Local\Temp\ventoy" c:\temp\ /q /h /e /r /k /y
981 File(s) copied

The xcopy command works for most other people and it worked for you on a different PC. So there must be something different about the TEMP folder on your system. I do know that XCOPY fails when copying from a compressed folder to the root of a FAT32 drive if the source path does not end in \. So what is 'special' about your TEMP folder if it is not compressed or encrypted?

there is absolutely nothing wrong with my destination folder.

you are relying on an 35 years old officially deprecated tool which on my OS does not accept a source path ending with a backslash

 

robocopy is not in XP which is why I avoid it.

I didnt say there was anything wrong with your destination folder.

I asked about the source folder.

The command with the source path ending in \ works for everyone else and on your other system, so I am curious to know what is different about your Windows system that makes it fail?

For instance if the source folder is a different drive, does it still fail in the same way?

If the source contains different files does it still fail?

The latest version of agFM (same version number) now uses \*.*

 

there is also nothing unusual about %temp% folder.

see above edited comment screenshot where xcopy fails on any source ending in backslash, using totally e2b-unrelated files and folders

here is same XCOPY failure on a different machine, same os version ltsc 2019

by the way, none of the examples in microsoft xcopy documentation show a source ending on backslash:

 

xcopy | Microsoft Learn

I mean, no disrespect here, and truly appreciate and thank you again for your time spent digging this through chat, but please consider that maybe you were invoking xcopy the wrong way all the time 😊

hm, one interesting find: in vista they added an explicit text about deprecation when invoked with /?

" In fact, if you run XCOPY /? in Vista, the help text begins with this:

NOTE: Xcopy is now deprecated, please use Robocopy."

this text seems to be missing from later versions, so despite wikipedia claim to be deprecated, I take that back as it seem to be included even in windows 11.

Robocopy built into Vista | Microsoft Learn

The original Add_Ventoy.cmd did not have a \ at the end of the source path.

Then someone reported that the command failed.

It turned out that the command failed only when copying from a compressed folder to the root of a FAT32 drive.

To work around this issue, I changed the source path so it ends in \ - this seemed to fix the problem and it worked fine on Windows 10 and 11 on both compressed and non-compressed folders.

Since then no one else has reported an issue with the batch file until you.

You also reported that the batch file worked on a different system.

That is why I would like to try to work out why the command fails on your system (and only your one system?).

For the time being I have changed the cmd file to use \*.* in the xcopy command.

 

Quote from steve6375 on 2022-11-24, 6:50 PM

Since then no one else has reported an issue with the batch file until you.

As I mentioned earlier in the thread, there is at least one report of the same error messages in the comments of the blog, I pasted the link. Keep in mind that for each report there are statistically more unreported cases. Signing up just for reporting an issue versus maybe finding a different machine/usb could be more burden to someone.

 

Quote from steve6375 on 2022-11-24, 6:50 PM

You also reported that the batch file worked on a different system.

That is why I would like to try to work out why the command fails on your system (and only your one system?).

I also mentioned earlier in the thread that it fails on a second machine, both on OS LTSC 2019, I've even pasted a screenshot!

 

Quote from steve6375 on 2022-11-24, 6:50 PM

For the time being I have changed the cmd file to use \*.* in the xcopy command.

thank you!

 

Quote from steve6375 on 2022-11-24, 6:50 PM

To work around this issue, I changed the source path so it ends in \ - this seemed to fix the problem and it worked fine on Windows 10 and 11 on both compressed and non-compressed folders.

Yes, but nowhere in any Microsoft documentation there is source example shown ending in backslash. It just happened to work 99% of the time then suddenly LTSC 2019 does not accept backslash, which does not contradict the documentation in any way

As I mentioned earlier in the thread, there is at least one report of the same error messages in the comments of the blog, I pasted the link.

That was the case I was referring to which turned out to be a bug in XCOPY when copying from a compressed NTFS folder to the root of a FAT32 drive. I reproduced the issue on my system by changing the temp folder to be a compressed folder. Many other sites show using xcopy with the source ending in just \ and it worked on my system and the reporters system and AFAIK every other Windows system - except for one of yours.

eBooks available (in PDF format)

I have written some easy-to-read eBooks which are available in PDF format (each eBook is over 100 pages) – rated 4.5/5 stars.
Learn the secrets of Legacy and UEFI USB booting and then make your perfect multiboot USB drive.
E2B eBook #1 includes instructions on how to remove the E2B 5-second start-up delay blue screen.

Most eBooks are over 100 pages long, contain original content and step-by-step exercises which are suitable for both the beginner or the more experienced user.
Customer reviews are located at bottom of each eBook product page and multi-buy discounts are available when you buy more than one eBook. Please also visit RMPrepUSB.com and the E2B Forum.
Subscribe to my blog for the latest news, tips, USB boot articles and free eBook updates.