Restored Word files have invalid paths

[BobW]

All word 2000 files that I restore from backup, appear in their Windows 2000 directory window with correct file sizes and types, but cannot be opened.

 

instead, the following Microsoft Word dialog appears:

 

"The document name or path is not valid. Chedk the file permissions for the document or drive. Use the File Open dialog to locate the document."

 

None of these steps fixes the problem.

 

Furthermore, any attempt to drag or copy the restored files to another location causes the following Windows 2000 error message:

 

"Error moving File or Folder - cannot move [filename]: the file can not be accessed by the system."

 

I have gone into the enclosing folder and assigned complete control privileges to 'everyone' but this does not fix the problem.

[kaikow]

That sounds like a serious bug.

 

Is it Fat, Fat32 or NTFS file system?

 

Has Dantz responded?

[kaikow]

Ooops, I forgot to mention.

 

You should run the equivalent of Scandisk.

For example, go to the Tools menu in the drive properties and run the error checking.

 

And/or run something like Norton Utilities' Disk Doctor.

[kaikow]

Has this thread been resolved?

I've not seen a response from Dantz and it's been 10 daze.

[Mayoff]

Dantz has not had any other reports of this type of problem. If you are unable to move the files inside Windows explorer, then I expect something strange is going on with the disk. I agree with another poster who suggested running Scan Disk/Norton to see if anything is found.

 

 

 

What type of restore was this? Did you restore the entire disk along with the system, or did you just restore a specific directory?

 

 

 

If you try another restore, just restoring a handful of these documents to a new folder or a different disk, does it happen again?

[kaikow]

I was the one who suggested using scandisk.

 

I was disappointed that Dantz had not not yet responded to the thread.

 

Dantz should contact the original poster to find out the status of the problem.

And the original poster, or Dantz, should report the resolution here.

[AmyJ]

This customer has been in contact with Dantz and is working on this issue with Technical Support directly.

 

Please remember that the forum is a community based self help tool, and is not an official means of contacting Dantz Technical Support. While we heavily monitor the forum, the amount of daily traffic prevents us from replying to every post.

[kaikow]

Yes, but this is a serious enough issue that a response should be posted here.

 

If a result of user error, then let us know so we need not suffer the same pain.

If a result of a Retrospect bug or interaction problem with MSFT software, heck, we need to know that too!

 

These forums can serve a very useful purpose by:

 

1. Allowing users to benefit from the knowledge of others.

2. Allowing Dantz to communicate solutions more easily.

3. Allowing Dantz to, perhaps, find others having the same problem.

4. Overall, proper use of these forums by users, and by Dantz personnell, should lower Dantz's support cost.

 

As to the allegation that the forum is not an "official" means of contacting Dantz.

That's nonesense.

Any company not bright enough to monitor such forums won't be around too long.

 

I was glad to see that folkes from Dantz do respond to many threads.

But don't respomd by saying "we haven't seen any other reports of the problem?, after all, somebody has to be the first to encounter each problem.

 

The problem raised in this thread is very serious.

If the suggestion to try Scandisk did not cure the problem, that's even worse.

 

Oh well, 'nuff of religious discussion.

[kaikow]

Has this issue been resolved?

 

If so, what is the solution?

[kaikow]

I tried reproducing the problem using files creates with both Word 2000 and Word 2002.

 

Happy to say, I could not reproduce the problem.

[BobW]

I contacted Dantz tech support about this issue; the tech located an obscure, unfathomable Microsoft Knowledge Base article (# 262320) and suggested that I should take this issue up with our Network Admin.

 

He couldn't understand it, and neither could another network admin.

 

I called Microsoft but - guess what; since my copy of Win2K was provided by Dell, they wouldn't help me; they told me it was Dell Computer's responsibility to figure out what the problem was.

 

I queried Dell's Tech Support via Email on Nov 23 '03 - so far, no response.....

 

Here's the message I sent them:

 

"I have copied 12 gigabytes of files and folders from my

company's NT server directory to my Inspiron, using Dantz Retrospect for

Windows (www.dantz.com) version 6.5283.

 

Copied to my laptop hard drive, some of the files cannot be accessed by the

system. For an incomprehensible explanation of this problem, please see

Microsoft Knowledge Base article # 262320. I cannot understand it, and

neither can our network engineers.

 

Microsoft says that they are not responsible for supporting my Windows

installation because it was an OEM version of Windows 2000, so they refuse

to help me with this problem. Microsoft refers me to Dell, who supplied the

OS and they claim therefore is responsible for solving all OS issues for me.

 

Dantz says their program has absolutely nothing to do with my problem, that

it is a Microsoft Windows problem. I believe them because the backup mode

that I am using with Retrospect is a simple file/folder copy scheme...Dantz

is not modifying the files/folders in any way, just copying them.

 

I need to find out why this happens so that our backups are fully usable.

Until this problem is solved, a disaster could destroy years of work."

 

 

[kaikow]

Although MSFT will not give you free support, I do believe that you can get for fee support.

 

[mikebk]

I think I have seen similar symptoms when the path to a Word document is "too long". The value of "too long" depended on file system type and operating system.

 

Restored files end up with longer path names than they had before unless it's a whole partition that is restored. Try restoring into a spot in your My Documents folder.

 

Hope this helps.

 

Mike

[kaikow]

Quote:

---

mikebk said:

I think I have seen similar symptoms when the path to a Word document is "too long". The value of "too long" depended on file system type and operating system.

 

Restored files end up with longer path names than they had before unless it's a whole partition that is restored. Try restoring into a spot in your My Documents folder.

 

Hope this helps.

 

Mike

 

---

 

The actual path for "My Documents" is usually long, e.g., "J:\Documents and Settings\Default User\My Documents".

 

If length of path is the problem, creare a directory in the root of one of the drives and restore stuff there.

[BobW]

Thanks for the ideas...i eagerly tried them with a much-shortened path length but regardless of path length, the Retro-backed up and/or Retro-duplicated versions of certain files still cannot be accessed by the system. This happens whether I use Retrospect's Backup OR Retrospect's Duplicate functions, and it happens on both my laptop and my desktop PC...it doesn't seem to matter which PC I am backing up to...the process of creating the backup or creating the duplicated file, seems to impose or reveal some kind of fatal file system error.

 

Their enclosing folder can be moved, but some of the files in it cannot be opened, erased, moved, or in any way accessed...even though nothing appears to be wrong with their parent files on our file server volume. The parents remain fully accessible from the server, and I can drag-copy them to my HD and they arrive intact and usable.

 

Only when they are processed by Retrospect, does the defect occur.

 

Again, possible hints to this phenomenon is noted in obscure, unfathomable Microsoft Knowledge Base article # 262320. Hopefully some rocket scientist will see this post and come forth with a cure!

 

 

 

 

[BobW]

One other thing: If i go back to the original file on the server, open it, and modify it in any way (ie, add a space or a period or an extra carriage return, or even just make a slight change in the file properties dialog) and then re-run my backup or duplicate session, the resulting new backup or duplicate version of the file is no longer defective...its accessible by the file system.

 

So, that seems to fit with Microsoft's Knowledge Base post, in that re-saving the file forces a rewrite that may apparently restore some kind of file parameter to the file, making it once again able to be backed up or duplicated with successful results.

 

Of course, since there are about 28,000 files in this backup set, going through them all manually and opening and altering and saving each defective file, is out of the question.

 

And, not knowing why this phenomenon happened in the first place, means there's no guarantee other files in the future won't also suffer the same fate, so even if i fixed all of them now, until i understand and can eliminate the underlying error, i'm still not out of the woods.

 

I'd be curious whether others have these kinds of inaccessible files in their backup sets, but don't know it. It would require some kind of utility program to scan through an entire backup set, to detect any such files....otherwise they might lurk there, for years, and the user may never chance upon one, and thus have a false sense of security, thinking they are all safely backed up... it's really quite a dilemma.

[kaikow]

I haven't looked at the MSFT article, but I'll say two hings.

 

1. Many years ago, it was possible to create a file in MS-DOS that could not be accessed after creation in a normal manner.

 

2. Just last week, I decided to move about 500MB of files from 1 drive to another. I could not move 1 file because Windize told me that the path was too long. So there still must be some file system gremlins lurking.

 

Perhaps it is possible to rename/move the files programmatically?

 

Does Windows Explorer let you browse to the file?

Does the file get listed if you do a Dir at a command prompt?

 

Can you open the file with a hexeditor program such as Frhed (see http://www.kibria.de/)?

[kaikow]

Scandisk should fix such problems.

 

Have you tried, say, Norton Utilities Disk Doctor?

[BobW]

path is not too long

 

can't rename or move the file by any means whatsoever.

 

can only move it or delet it, if i delete or move its enclosing folder.

 

Explorer displays the file and lets me delete or rename it, but when it is renamed it still cannot be opened (can't be accessed by the system).

 

DOS can't seem to locate the path to the enclosing folder.

 

Can't open with a hexedit program.

[BobW]

tried ScanDisk and Norton Utilities. No luck there, either.

 

 

 

I tried Windows Backup; I backed up one of the bad files from its original server location to a USB drive attached to my laptop. Then I restored it to the laptop's HD. Once restored, it could not be accessed by the system.

 

 

 

Summary:

 

 

 

The original file is fully usable on the server and fully usable if you drag copy it to the local HD, but is rendered unusable if I use Dantz Retrospect to back it up to the local HD or duplicate it to the local HD, and is also rendered unusable if I use Windows Backup to back it up and then restore it locally.

 

 

 

Since Windows Backup also produces the problem, that appears to let Dantz off the hook; I guess it's a Microsoft issue. I'll try their overpriced paid support and post a solution here if I am lucky enough to find a solution...Certainly it would be something that Dantz would be interested in knowing about...

 

 

 

 

[kaikow]

I suspect a file system naming problem.

 

 

 

One used to be able to overcome this by doing the following:

 

 

 

1. Depending on the OS, open up a Command window, or an MS-DOS window.

 

2. CD to the directory in which the file lives. I suggest CD-ing a directory at a time to get there, not by using the entire path at once.

 

3. Rename the file to a really short name and hope that fixes the problem.

 

 

 

Haven't tried the above in years, so dunno if it will still work.