Cannot copy &amp;lt;certain file&amp;gt; The path is too deep

"delete a file or folder is like copy process" NADIR said .
You Cannot Delete a File or a Folder :
Cause 4: Files Exist in Paths That Are Deeper Than MAX_PATH Characters
You may not be able to open a file if there are issues with the file path.
Resolution 1: Use an Auto-Generated 8.3 Name to Access the File
To resolve this issue, you may want to use the auto-generated 8.3 name to access the file. This resolution may be the easiest resolution if the path is deep because the folder names are too long. If the 8.3 path is also too long or if 8.3 names have been disabled on the volume, go to Resolution 2.

For additional information about disabling 8.3 file names on NTFS volumes, click the article number below to view the article in the Microsoft Knowledge Base:
121007 How to Disable the 8.3 Name Creation on NTFS Partitions

Resolution 2: Rename or Move a Deep Folder
To resolve this issue, rename the folder so that the target files that are deeper than the MAX_PATH no longer exist. If you do so, start at the root folder (or any other convenient place), and then rename folders so that they have shorter names. If this step does not resolve this issue (for example, if a file is more than 128 folders deep), go to Resolution 3.
Resolution 3: Use a Network Share That Is As Deep As the Folder
If Resolution 1 or Resolution 2 is not convenient or does not resolve the issue, create a network share that is as deep in the folder tree as you can, and then rename the folders by accessing the share.
Resolution 4: Use a Tool That Can Traverse Deep Paths
Many Windows programs expect the maximum path length to be shorter than 255 characters; therefore, these programs only allocate enough internal storage to accommodate these typical paths. NTFS does not have this limit and it is capable of accommodating much longer paths.

You may experience this issue if you create a share at some point in your folder structure that is already fairly deep, and then create a deep structure below that points by using the share. Some tools that operate locally on the folder tree may not be able to traverse the entire tree starting from the root. You may have to use these tools in a special way so that they can traverse the share. (The CreateFile API documentation describes a method to traverse the entire tree in this situation.)

Typically, you can manage files by using the software that creates them. If you have a program that can create files that are deeper than MAX_PATH, you can typically use that same program to delete or manage the files. You can typically delete files that are created on a share by using the same share.

http://support.microsoft.com/?kbid=320081

ASKER

I looked at and its hard to follow and doesnt really apply....

The files is like X:\something.iso and the destination is Z:\something.iso. These are on the same machine so its not network related. The name of the fiel being copied is far less than the max of 256.....

Try this:
At a command prompt, change to the parent folder containing the file or folder you are attempting use.
To assign a drive letter to the location, type the following command

subst <drive>: .

where <drive> is an available drive letter and "." is a period, indicating the current folder.
Type exit, and then press ENTER.

ASKER

I dont have virtual drives set up, and it woulnt seem to allow me to create one...plus im not sure how that would help...when i said the drives were the same I ment that they are the same model # but are 2 seperate physical disks

Virtual: Non-existent. Made up. Unreal.

I'm suggesting you create virtual drive with the subst command.

subst
Associates a path with a drive letter.

SUBST [drive1: [drive2:]path]
SUBST drive1: /D

drive1: Specifies a virtual drive to which you want to assign a path.
[drive2:]path Specifies a physical drive and path you want to assign to
a virtual drive.
/D Deletes a substituted (virtual) drive.

Type SUBST with no parameters to display a list of current virtual drives.

s317on :

Did you try my comment ?

ASKER

yes I read it but it dont see how it helps.....ill explain again

My box has 2 hard drives, disk1,disk2

disk1 has 2 partitions, C and Z
disk2 has 1 partition X

there is a file in the root of X that I can not copy to the root Z. I have tried changing the name of the file to 1 character and that does not help.....can anybody explain why this would happen?

stevenlewis

try this
open windows explorer to where the file is
open a command prompt type
copy "
then from explorer drag the file to the command prompt
then put a " at the end
then type the dest directory you want and hit enter

Have you tried using the XCOPY command instead of the copy command?

use Disk managemnet then do RESCAN for new HDD
then try again .

can you create new file on it ?

I doubt the problem is in the naming HDD ?

did you name it your selfe ?

rename it to be like the following :

disk1 has 2 partitions, C and <X>
disk2 has 1 partition <Z>

the system have to naming the HDD by starting the naming for Disk1 from A B C D E ...etc
then go to Disk2 then complete by F G letters but I see that disk1 has Z and Disk2 has X

ASKER

Nope renaming didnt work and copying from command line returned an error with semapore timeout

ASKER

Yes I named them my self and i have full access as far as writing and deleting files. I can view it fine and everything...just cant copy certain files from it

What is the error message that appears when you do copy from CMD.EXE ?
If it means that the file is not found ..etc , then :

Look to the end of file names they may have trailing space or a trailing period or the file name consists of a space only
------------------------
Cause 5: The File Name Includes an Invalid Name in the Win32 Name Space
You may not be able to delete a file if the file name includes an invalid name (for example, the file name has a trailing space or a trailing period or the file name consists of a space only). To resolve this issue, use a tool that uses the appropriate internal syntax to delete the file. You can use the "\\?\" syntax with some tools to operate on these files, for example:
del "\\?\c:\path_to_file_that contains a trailing space.txt "

The cause of this issue is similar to Cause 4. However, if you use typical Win32 syntax to open a file that has trailing spaces or trailing periods in its name, the trailing spaces or periods are stripped before the actual file is opened. Therefore, if you have two files in the same folder named "AFile.txt" and "AFile.txt " (note the space after the file name), if you try to open the second file by using standard Win32 calls, you open the first file instead. Similarly, if you have a file whose name is just " " (a space character) and you try to open it by using standard Win32 calls, you open the file's parent folder instead. In this situation, if you try to change security settings on these files, you either may not be able to do so or you may unexpectedly change the settings on different files. If this behavior occurs, you may think that you have permission to a file that actually has a restrictive ACL.

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

same thing happens as when i run scandisk it gets to 9% on stage 4 then stops....