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:
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:
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.
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 PMSince 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 PMYou 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 PMFor 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 PMTo 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.
I would guess that the version of XCOPY in LTSC 2019 had a bug (or is 'special') then?