Failed DOS MOVE command - Bad destination path - Wheres my files?

You can also perform a search - they'll turn up...

did a search without luck - also no spaces in the origin or destination paths

Any other ideas?

Can you post the paths that you used?

I'm afraid the worst thing you could possibly do is to copy a bunch of files to a non-existent directory followed by a block-delete, because DOS simply interprets the non-existent directory name as a filename and you end up with just a single file being just a copy of the last file copied and all your files gone forever!

But the MOVE command doesn't let DOS do that anymore - thankfully. Also, MOVE won't attempt to move files or directories to a bad path so, if you inadvertently attempt to move C:\TEMP to D:\MY TEMP FILES (without using double-quotes) then MOVE will refuse to move your files if D:\MY does not exist.

As far as I am aware, it's safe to say if you simply move your files and not follow the MOVE command with a DELETE command (thinking the files are 'copied' to a 'bad' location and forcing a delete because they were still there) then the files are still somewhere on your system.

The question that now remains is, what was the actual MOVE command you used to move your files?

Finally, although not obvious, have you tried Windows' search facility to search for the files by specifying at least one known filename you can actually remember?

You can also do this from a DOS command line such as:

   DIR /s c:\"My File.txt"

if amongst the files you've lost, one of them is named 'My File.txt'. On the other hand, if you've lost a bunch of MP3 files then you could used:

   DIR /s c:\*.MP3

In both cases, DIR will search the whole of drive C: for the file/s. You can substitute the 'c:\' for any other drive letter such as 'd:\' or 'e:\' or whatever.

One final point. If your files are HDDEN - that is, their 'hidden' attributes are set, then DIR /S on it's own will fail to find it in which case you can use any of the two commands (I actually prefer the ATTRIB command myself):

   DIR /ah /s "c:\My File.txt"

or

   ATTRIB /s "c:\My File.txt"

or in the case of a bunch of MP3 files:

   ATTRIB /s c:\*.MP3


Best of luck!

Re-posted due to typing error:

I'm afraid the worst thing you could possibly do is to copy a bunch of files to a non-existent directory followed by a block-delete, because DOS simply interprets the non-existent directory name as a filename and you end up with just a single file being just a copy of the last file copied and all your files gone forever!

But the MOVE command doesn't let DOS do that anymore - thankfully. Also, MOVE won't attempt to move files or directories to a bad path so, if you inadvertently attempt to move C:\TEMP to D:\MY TEMP FILES (without using double-quotes) then MOVE will refuse to move your files if D:\MY does not exist.

As far as I am aware, it's safe to say if you simply move your files and not follow the MOVE command with a DELETE command (thinking the files are 'copied' to a 'bad' location and forcing a delete because they were still there) then the files are still somewhere on your system.

The question that now remains is, what was the actual MOVE command you used to move your files?

Finally, although not obvious, have you tried Windows' search facility to search for the files by specifying at least one known filename you can actually remember?

You can also do this from a DOS command line such as:

   DIR /s "c:\My File.txt"

if amongst the files you've lost, one of them is named 'My File.txt'. On the other hand, if you've lost a bunch of MP3 files then you could used:

   DIR /s c:\*.MP3

In both cases, DIR will search the whole of drive C: for the file/s. You can substitute the 'c:\' for any other drive letter such as 'd:\' or 'e:\' or whatever.

One final point. If your files are HDDEN - that is, their 'hidden' attributes are set, then DIR /S on it's own will fail to find it in which case you can use any of the two commands (I actually prefer the ATTRIB command myself):

   DIR /ah /s "c:\My File.txt"

or

   ATTRIB /s "c:\My File.txt"

or in the case of a bunch of MP3 files:

   ATTRIB /s c:\*.MP3


Best of luck!

thanks t0t0 - I did use on an XP pro box a DOS batch file with each line of the form:

MOVE "X:\OrginPath\File01.abc" "Y:\DestinationPath\"
MOVE "X:\OrginPath\File02.abc" "Y:\DestinationPath\"
MOVE "X:\OrginPath\File03.abc" "Y:\DestinationPath\"

The destination path didn't exist and - like you said - all I have is a mystery "file".
Looks bad, eh?

SirBounty - I'll post the specific paths tomorrow back at office but they were environmentally contextual - one was an internal drive - the other, the destination, was on an external drive. Drive letters used in both paths.

If you explicitly specified:

    MOVE "X:\SourcePath\SourceFile.ext" "Y:\DestinationPath\"

then unless "Y:\DestinationPath\" actually exists, they sould NOT have moved at all.

The worst thing that could of happened is you issued the following command (notice the missing trailing '\' at the end of the destination path name):

    MOVE "X:\SourcePath\SourceFile.ext" "Y:\DestinationPath"

In this case, 'DestinationPath' would be interpreted as a filename and all you files will disappear in a black hole named Y:\DestinationPath. So, look in the Y:\ folder for a file named 'DestinationPath'.

Ouch!! I hope you were right about the trailing backslash character.

By the way, if you open your mystery file in Notepad, although most of might look like a load of gobbledegook, you may stumble across some text which mich identify it as one of your lost files.

I hope not though...

PS. You can drag-and-drop the mystery file straight into Notepad if it's Notepad is already open.

I would say that if you have even the vaguest suspicion that your files have been deleted into a void, and if those files are of significant importance to cause you great inconvenience over their loss, then you should really stop using that hard drive and try a recovery program to see if they are recoverable.

Usually that involves removing the drive from which you wish to recover files, and attaching it temporarily as a slave drive to a compatible Windows PC from which you run the recovery program and specify the slave drive as the target.

Suggested program is GetDataBack.  You choose the version (FAT or NTFS) to match the filing system of the drive you are recovering from.  Trial mode is functional up to the point where it displays recovered files, but copying out the files to safety requires payment of a license.

I'm going to try and simulate what seems to have happened, and see what might be possible with your "mystery file".

XP SP3.   C:\TEST folder exists as do the 3 files I created.  I have no Y: Drive, and therefore "DestinationPath" cannot exist.

@echo off
MOVE "C:\TEST\File01.abc" "Y:\DestinationPath\"
MOVE "C:\TEST\File02.abc" "Y:\DestinationPath\"
MOVE "C:\TEST\File03.abc" "Y:\DestinationPath\"
exit

C:\TEST remains where it is and the files remain where they are.  I cannot detect the creation of any new folders or files bearing any of the names.

- The same is true if I leave off the trailing backslashes from the destination.
- Removing all double quotes - same result, ie. nothing.
- No double quotes or trailing backslashes after destination - same as above.
- Same as above but create a space in destination directory - same results.

BillDL

>> "The same is true if I leave off the trailing backslashes from the destination"

Try running the same commands WITH a Y: and a bad path. Then you'll get the drift. Oh, and if you don't have a Y: drive, then create one with SUBST.

>>"Removing all double quotes - same result, ie. nothing"

BillDL, we all know double-quotes ONLY (normally) effect filenames and directory names containing spaces or certain special characters.

>>"No double quotes or trailing backslashes after destination - same as above"

Once you've created your Y: drive, see what happens to your files if you remove the backslash from a bad destination path.

Your test tells us nothing. In fact, it tells us less than nothing becuase I made a point of mentioning both double-quotes and the backslash character and you have played these down.

You obviously failed to recognise that MOVE will abort at the first hurdle - at the fact there is no Y: drive. So I suggest you create a Y: drive using SUBST and give more thught to your diagnostic testing before disproving another expert's findings.

In the meantime, I urge bcombe to totally ignore BillDL's previous comment until BillDL confirms his findings after following my suggestions.

bcombe

Please read my previous comment to DillDL

t0t0,
are you really sure you tried that out? I have the same results as BillDL, as I would have expected:

cd c:\temp\ee\tst
copy nul a & copy nul b
subst y: c:\temp\ee\tst
move * y:\mva

does result in an error message not allowing multiple files to be moved into a single one. A backslash at the end doesn't change anything.

move a y:\mva
move b y:\mva

results in first file moved and renamed, second NOT, getting an overwrite prompt, of course.


Mysterious files are sign of bad cache memory or unreliable hard disk.

Hi Qlemo

The point addressed by t0to with reference to my comment was really the fact that my destination drive did not exist, and this was therefore the first point at which the move command would have been expected to fail with no apparent sign of activity or error message.  I kind of lost direction of what I was doing away from this question as I tried to create an extensionless file using as many permutations of bcombe's original commands as I could.  I really wanted to try and recover his files but in the end all I could get was a copy of the last file"moved"  but without the extension, which was the most expected result.  I was actually trying to get what your error message told you wasn't possible, ie. "multiple files moved into a single one" to examine and extract separate files from, if that were to be possible.

I kind of type my observations in Notepad as though I'm talking to myself when I'm looking at a problem, so it sometimes comes out sounding like a lawyer cross-examining evidence in a court room even though it is often meant more as a "right, so that works, but this didn't, hmmm...why not?" transcribed thought.

Qlemo

You know I respect you highly and reading your comment has prompted me to double-check, then double-check again.

Basically, if you MOVE a file (or group of files) to a bad pathname and you do not include a trailing backslash as part of the pathname, then the file/s disappear into a blackhole leaving just a single file whose name is the name of the target directoryname of the path.

The same applies to COPY too so it's not surprising MOVE behaves in the same manner. XCOPY, on the otherhand, prompts you to specify a filename or directoryname.

If you include a trailing backslash in your target directoryname then DOS will moan if the directory does not exist and the MOVE (or COPY) will fail. See below.

 

C:
CD \
MD source
MD destination

SUBST x: c:\source
SUBST y: c:\destination

MD x:\OrginPath
MD y:\DestinationPath

X:
CD OrginPath
COPY NUL File01.abc
COPY NUL File02.abc
COPY NUL File03.abc

C:
MOVE "X:\OrginPath\File01.abc" "Y:\DestinationPath\"

REN "y:\DestinationPath" "DestinationPat_"

MOVE "X:\OrginPath\File02.abc" "Y:\DestinationBadPath\"
The system cannot find the path specified.

MOVE "X:\OrginPath\File03.abc" "Y:\DestinationBadPath"

FOR /F %a IN ('DIR /A-D /B /S x:\') DO @ECHO %a
x:\OrginPath\File02.abc

FOR /F %a IN ('DIR /A-D /B /S y:\') DO @ECHO %a
y:\DestinationBadPath
y:\DestinationPath\File01.abc

NOTE: y:\DestinationBadPath is actually a file - the missing File03.abc

When MOVEing multiple files, the same happens to the first file however, DOS moans saying it "Cannot move multiple files to a single file"

Even moving files singularly one file at a time, DOS will moan at any subsequent files you attempt to move to the same bad path.

However, if you specify the '/Y' command option with MOVE then DOS will not complain and simply chuck all your files into a black hole and you lose all but the last file.

One possibility that springs to mind is that his destination referred to a removable media such as a USB device. And rather than the files actually being written out to the device before unplugging it, they were only cached.

BillDL

You've been around a long time and infact, I remember you from some 7 years ago when I joined EE so I have good respect for you.

The odd thing about this problem is that, to lose multiple files as he has done, he would of either have had to specify the /Y option with MOVE or (and this sound very far-fetched but not unheared of) specified a different bad destination path for each file moved.

In the first case, he will have lost all but the last file moved, as you quite rightly say however, in the second case, he would have ended up with lots of files without extensionnames in the 'parent' directory of his bad destination pathname. In the example given, they would be found in Y:\.

If he is suspects his files are somewhere (anywhere) on his hard disk drive/s, and if he can recall even a single unique phrase or word in any of his 'lost' files then he could try a search of ALL files 'contining..." which is great for text files but not very helpful for non-text files.

Finding just the last file (or extentionless file) might give a clue as to what may have happened to the rest of his files.

Oops! ... search of ALL files "containing..."

Qlemo

Didn't I say that in my post above?

.... and to add to your comment....

>> "The second file will hit the overwrite prompt"

providing you don't use the /Y option with MOVE otherwise, you won't hit the overwrite prompt and you'll lose a lot more than just the single file !!

Reading the move help, I found two interesting points:

1. /y can be provided by a COPYCMD environment variable 
2. Default is to be prompted for overwrite, except when called in Batch File 

Ouch!! Well spotted Qlemo.

Very interesting.... I don't think we can go any further with this one. This is conclusive evidence his files have gone to file-heaven.

Great work Qlemo.

In answer to bcombe's question, there is a possibility he may be able to recover ONLY the last file MOVEd. All other files are gone forever!!

The last file will have no extension, will be named 'DestinationPath' (working from data given) and can be found in the 'Y:\'.

bcombe

Any progress?

Really sorry for delay. You folks are great.