Solved

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

Posted on 2009-04-06
29
1,161 Views
Last Modified: 2012-05-06
I made a batch file with a move command per line.
MOVE X:\OrginPath Y:\DestinationPath
The destination path was incorrect. The files are gone from the orgin directory.

Are the files irretreveable ? Are the files pages somewhere in RAM or buffered on disk in some normally invisible system 'folder' ? Any options at all?
0
Comment
Question by:bcombe
  • 14
  • 5
  • 4
  • +2
29 Comments
 
LVL 67

Expert Comment

by:sirbounty
ID: 24080367
Check the directory - if it has a space -odds are it's in the first portion of that foldername...
Example:

Move c:\data\*.* f:\my data\

would potentially be in f:\my folder

Always enclose your directories with quotes to prevent this:

move "C:\data\*.*" "f:\my data\"
0
 
LVL 67

Expert Comment

by:sirbounty
ID: 24080372
You can also perform a search - they'll turn up...
0
 

Author Comment

by:bcombe
ID: 24080782
did a search without luck - also no spaces in the origin or destination paths

Any other ideas?
0
 
LVL 67

Expert Comment

by:sirbounty
ID: 24080793
Can you post the paths that you used?
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24083854
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!
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24083866
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!
0
 

Author Comment

by:bcombe
ID: 24084006
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?
0
 

Author Comment

by:bcombe
ID: 24084027
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.
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24084113
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.

0
 
LVL 16

Expert Comment

by:t0t0
ID: 24084124
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.
0
 
LVL 38

Expert Comment

by:BillDL
ID: 24087278
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".
0
 
LVL 38

Expert Comment

by:BillDL
ID: 24087470
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.
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24087667
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.



0
 
LVL 16

Expert Comment

by:t0t0
ID: 24087677
bcombe

Please read my previous comment to DillDL
0
Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

 
LVL 68

Expert Comment

by:Qlemo
ID: 24095015
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.


0
 
LVL 38

Expert Comment

by:BillDL
ID: 24095335
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.
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24095963
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.


0
 
LVL 16

Expert Comment

by:t0t0
ID: 24095982
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.
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24096167
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.
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24096185
Oops! ... search of ALL files "containing..."
0
 
LVL 68

Assisted Solution

by:Qlemo
Qlemo earned 80 total points
ID: 24096291
t0t0,
"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."

That's true for a single file. The second file will hit the overwrite prompt.

0
 
LVL 16

Expert Comment

by:t0t0
ID: 24099392
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 !!
0
 
LVL 68

Expert Comment

by:Qlemo
ID: 24099499
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
Maybe that is causing the confusion ... The latter is true, the prompt is only shown if in interactive mode!
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24101361
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:\'.
0
 
LVL 38

Assisted Solution

by:BillDL
BillDL earned 120 total points
ID: 24105257
bcombe
With this kind of certainty, your only chance now of recovering the files (apart from the last named one in your batch file) is as I mentioned in my comment ID:24087278  
" ... 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."

In the end, t0t0 answered your question with his comment ID:24083854

"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!"

The rest of the comments have just reinforced that answer, or served to prove that this is exactly what has happened to your files.
0
 
LVL 16

Accepted Solution

by:
t0t0 earned 300 total points
ID: 24105669
bcombe

Thank you for pointing that out BillDL. I mentioned that very early on however, I would be more than happy for credit to be shared among us for some great detective work carried out. These are (in no particular order):

t0t0 - correctly identifying the cause of  bcombe's missing files (24083854).

BillDL - suggesting the removal of bcombe's hard disk drive for data retrieval

Qlemo - great detective work in confirming MOVE's behaviour when using the '/Y' option which reinforced the solution beyond doubt (24099499).

bcombe, please award point accordingly.


My final word on this is, there is a slim possibility of recovering files from a hard disk drive under these circumstances if the hard disk drive has been subjected to minimal change since your files disappeared.

What actually happens at the physical level during a MOVE (particularly in your case) is that your files are simply renamed one after another. To be specific, details of every file and folder (their names, location, date of creation etc., size and file attributes etc.) are stored in a part of the drive known as the FAT (File Allocation Table - in DOS) or the MFT (Master File Table - in NTFS) which is not normally directly accessible to users. When a file is deleted, the file itself remains intact on the hard drive until parts of it is eventually over-written by other data. It's the file's entry in the FAT or MFT that is actually modified indicating the file is deleted.

An undelete program will examine the entries in the FAT or MFT to determine the existence of deleted files. If it finds any, it tries to follow the links to file fragments, which may typically be spread over different parts of the hard disk drive, in an attempt to piece it back togehter. If it succeeds, your file is recovered.

If parts of the file is unrecoverable (usually because fragments of the file have been over-written), then the undelete program may fail to recover all or part of that file. This is because each file fragment includes a link to the next fragment and the undelete program tries to chain these fragments back together during the undelete process.

Some undelete programs will scan the hard drive's main storage area as well looking for any file segments which link to others and attempt to rebuild even just parts of the file.

A program which uses a combination of both these methods for recovering lost files is better suited for the success of recovery.

Data recovery of file fragments is great for files containing lists of tables of data such as an address book or tlephone directory or database as well as text files because it could significantly cut down on time required to re-enter the lost data.

Data recovery of fragments of images, music and video is trickier however, depending on their format, fragments may be successfully recovered and repaired as image, music or video snips.

Data recovery of fragments of compressed files is virtually useless unless either the start and/or end of the file is intact because these areas contiain key information for that particular compressed file and only under these circumstances is a repair tool likely to be able to recover some, if any, files from withing the compressed fragment. But don't hold me to this.


Steps you should take:

Remove your hard disk drive and attach it as a slave drive to another PC.
Use an undelete program or utility to examine the drive at the physical level.
Use an undelete program to scan the whole drive for chains of files fragments at the physical level.
No changes should be made to the hard disk drive even during the data recovery process.
0
 
LVL 16

Expert Comment

by:t0t0
ID: 24136163
bcombe

Any progress?
0
 

Author Closing Comment

by:bcombe
ID: 31567169
Really sorry for delay. You folks are great.
0
 
LVL 38

Expert Comment

by:BillDL
ID: 24752036
Thank you bcombe
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

The following is a collection of cases for strange behaviour when using advanced techniques in DOS batch files. You should have some basic experience in batch "programming", as I'm assuming some knowledge and not further explain the basics. For some…
TOMORROW TOMORROW.BAT is inspired by a question I get asked over and over again; that is, "How can I use batch file commands to obtain tomorrow's date?" The crux of this batch file revolves around the XCOPY command - a technique I discovered w…
This video discusses moving either the default database or any database to a new volume.
Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…

706 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now