No announcement yet.

DOS message "Not ready reading drive N:"

  • Filter
  • Time
  • Show
Clear All
new posts

  • DOS message "Not ready reading drive N:"

    In order to transfer several files of unknown size from drive C: of a PC to a network drive N:, I am using the following instruction.
    SHELL "COPY C:\Line01\??????M2.TXT N:\LINE01"
    As such, this works fine.
    However, if during the execution of this instruction the network goes down, DOS generates the following message:

    Not ready reading drive N:
    Abort, Retry, Fail?

    Then the program just sits there and waits for a keyboard input before returning to basic.
    The PC in question is unsupervised and does NOT have a display or keyboard attached.
    This means that there is NO manual way to continue, except for rebooting the PC.

    I do not care if the files actually got transferred or not, since I can check and handle this once back in basic.
    I am trying to find a way to exit the DOS shell or a way to continue on.
    Or any alternate way to accomplish the above file transfer.
    Transfer time is also a criteria, since reading in files one at a time and character by character and then writing them takes considerable more time then the above DOS command.

    Would appreciate any solutions, comments and suggestions.
    Helmut Bayer


  • #2

    I never use SHELL to copy files, and I never copy them one character at a time. Instead, I use a loop to select the files, like so:

    File$ = DIR$("C:\Line01\??????M2.TXT")
    WHILE LEN(File$)
      CALL CopyFile(File$, "N:\LINE01")
      File$ = DIR$
    My file copy routine uses BINARY file access and copies files in 16k blocks (16384 bytes). I'd use 32k, but PB can only handle strings up to 32750 (not 32768). 16k gives me pretty good optimization for the most common cluster sizes.

    The file copy routine I wrote is part of our Full Power Toolbox product ( ), so I can't share the code here. Sorry! (In addition to copying the file, it preserves the original date/time stamp on the file, so it is functionally equivalent to DOS' copy. And it is pretty close in terms of speed, especially when you factor in the overhead of the SHELL statement.)


    Alan C. Earnshaw
    Information Management Systems, Inc.
    Alan C. Earnshaw
    Information Management Systems, Inc.


    • #3
      I would also write a specialized program to copy files. Shelling
      on a network drive is not the best way to go.

      I don't know if int21h function 1ch will work on a network
      drive but you may want to try it to determine if the drive is
      still available.

      If it doesn't work, try (shudder) ON ERROR. I personally
      dispise this statement since it ususally indicates shoddy
      programming but sometimes, it's unavoidable. You can then
      end the program without it freezing up.

      There are no atheists in a fox hole or the morning of a math test.
      If my flag offends you, I'll help you pack.


      • #4
        How about using the COPYFILE() function in the DOSUNIT.BAS file supplied with PB/DOS ? Not only does it copy the file, is duplicates the original time/date stamp too.

        And the price is right...! (sorry Alan!)

        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        mailto:[email protected]


        • #5

          No apologies needed. I haven't explored the PB sample Units in a long time, so I did not remember seeing a CopyFile routine in them. I'm glad it's there!


          Alan C. Earnshaw
          Information Management Systems, Inc.

          Alan C. Earnshaw
          Information Management Systems, Inc.


          • #6
            Thank's for all the information!

            Did find the Copyfile routine and it is helpful.

            Did also find a way in DOS to accomplish this.

            Using the COMMAND /F will automatically fail the the DOS routine if the drive is not ready, thereby exiting the shell and returning to basic.
            The /F switch is a undocumented function of the COMMAND.COM structure.

            Thank's again, Helmut Bayer