windows - "There is no disk in the drive." error message from an application that was just copied from a CD with batch file xcopy but doesn't require it at all

18
2014-05
  • Doug

    All,

    I have an interesting problem that I have looked everywhere for an answer and have come up short. Hopefully someone out there can shed some light as to why this is happening.

    I have a CD that contains several C++ applications and a batch file that is ran to copy the files to the correct spots using XCOPY. Yes the xcopy operation happens successfully and the new applications are put in the correct spots.

    The problem I am having is right after the batch file has finished copying the file over, I close the batch file window, eject the CD, and run any of the newly copied applications from its new location on the computer. I get the Windows error "There Is No Disk in the Drive. Please Insert a Disk into Drive D:". (That is my CD drive's name)

    My programs do NOT have any references to any hardcoded/relative paths at all. In fact, once I acknowledge this error 4 or 5 times and reopen the program, I NEVER see the error again. To see the error pop back up again, I have to run the batch file again from the CD and take the CD out before I run the application.

    Just for more clarification, doing a manual copy/paste (Ctrl+c, Ctrl+v) of an application from the disk works just fine. If I manually copy/paste and eject the CD, the program works just fine. This error only occurs on the first time the program runs after I copy it over with a batch file and remove the CD before I run the program. Also, restarting the computer after the batch file is ran prevents this problem from happening altogether too.

    I know what you are saying, if restarting the computer after copying the file over fixes the problem, then why is he asking this question here? Well, I have to copy this file on 30+ non-networked computers at a time and it takes a LONG time to restart each of them.

    Is there some weird Windows tagging of the applications when they are copied over with XCOPY to where the program still thinks it lives on the CD after being copied over? Does anyone have any suggestions, comments, or links that can point me in the right direction? Any help would be phenominal.

    Thanks a lot!

    EDIT: I forgot to mention that this is on the Windows XP operating system.

    EDIT2: Here is the code for my batch file.

    @ECHO OFF

    SET INSTALLSERVER=%~dp0
    SET AppProgramFiles=%ProgramFiles%\ApplicationName\

    XCOPY "%INSTALLSERVER%Scenario\*.*" "%AppProgramFiles%Scenario\" /C /Y /q
    XCOPY "%INSTALLSERVER%Plan\*.*" "%AppProgramFiles%Plan\" /C /Y /q
    XCOPY "%INSTALLSERVER%Data" "%AppProgramFiles%Data\" /C /Y /q /e
    XCOPY "%INSTALLSERVER%Misc\*.*" "%AppProgramFiles%Misc\" /C /Y /q

    As I mentioned above, I can copy/paste the application myself and the program runs just fine. There is NO error if I do it this way. The "No disk in the drive" error ONLY shows up if I copy the application over using a batch file. In fact, I've seen the same problem if I copy an application over using a vbscript file as well. I'm wondering if Windows XP has some strange way of tagging applications that get copied off of a CD using a process like batch/vbscript? Any ideas?

    • Answers
    Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

    Related Question

    windows - Why is xcopy returning "invalid number of parameters"?
  • Slothman

    Under some circumstances, xcopy will return the error Invalid number of parameters without giving you a clue as to what’s going on. The usual solution for this is to be sure that your filenames are enclosed in quotes, as this can be an issue with batch files where you have something like xcopy %1 %2 and you really need xcopy "%1" "%2". I recently ran into a problem, however, where the problem wasn't spaces:

    C:\Temp\foo>c:/windows/system32/xcopy.exe /f /r /i /d /y * ..\bar\
Invalid number of parameters

    • Related Answers
  • Slothman

    The solution to this one was tricky: it turns out that xcopy is parsing the forward slashes in the path to its own binary. This works fine:

    C:\Temp\foo>c:\windows\system32\xcopy.exe /f /r /i /d /y * ..\bar\
C:\Temp\foo\blah -> C:\Temp\bar\blah
1 File(s) copied

    You can also run into this if you have your PATH defined using forward slashes instead of backslashes.