Duplicate DirID errors

[cpmoran]

Hi All,

 

Our client has a MacOS X 10.3.3 machine with Retrospect 6.0.193. Previously it was a MacOS 9.1 machine with Retrospect 4.2 from which they would mount their Windows 2000 Server SFM volume and archive off it not problems whatsoever.

 

Now with MacOS X, Retro 6 we get continuous "duplicate dirid, error -127 volume corrupt?" errors!

 

The volume is NOT corrupt, and we can read the folder in question on MacOS X, MacOS 9.x and Windows without issue.

 

I notice another frustrated post about this. It is not acceptable to say that AppleShare IP has never been supported, nor that the client should be used on the Windows 2000 Server because during the activation of the client, Retro specifically says you should mount the volume on the desktop.

 

What's the problem Dantz? I have a number of clients lining up for a refund.

 

Also, why do we have to put up with the inability to preview what files will be archived if you do an "immediate" backup from a mounted volume?

 

Retro 6 seems a seriously buggy backward step to me.

 

Regards,

 

Connor!

[natew]

Hello

 

Just like OS9, OSX has its own set of "features" that we have to endure.

 

One thing you should be sure to do is set Retrospect to automount the volume for you as outlined here: http://www.dantz.com/index.php3?SCREEN=kbase&ACTION=KBASE&id=27238

That way you can browse with immediate operations too.

 

The volume corrupt error could be caused by a bad folder name. Is there a path listed in the log next to the error? Try moving (not just copying) the folder to another volume and back again. That should recreate a new folder ID entry for the problem folder.

 

Can you direct us to the place that says Retrospect has never supported ASIP and the information about installing clients on services for mac servers? I'd like to make sure I understand what you are referring to.

 

Thanks

Nate

[shadowspawn]

I have been hit with the "duplicate dirid" problem once, and did not get to the bottom of it. (I thought there were some known causes, but it sounds like you have checked the archives?)

 

In my cases there were only a couple of folders, so I made new folders, moved across the contents, deleted the original now empty folders, and the problem has not recurred. So I don't know what the actual cause of the problem was, but for me there was an easy work-around.

[cpmoran]

Hi Natew and Shadowspam,

 

Thanks for your replies.

 

The folder name is listed in the error, and I can do as you describe. The problem in this particular instance is it just seems to move the problem. The volume our client is trying to archive gets upto 10Gb of data in it a week, in thousands of folders/files. This error means archiving is stop-start all the time, AND the error is spurious. It's perfectly possible to copy the contents of the error folder using Finder or Explorer on Mac 9/X or Windows.

 

As for the AppleShare IP comment, the end of this thread;

 

"Scanning fails b/c "Duplicate dirid" error"

 

Today I came across another client suffering this problem - they felt something was actually wrong with their server, but I showed them that it was not.

 

Is there some extra detailed logging I can turn on and send it somehow? I'd like to see this fixed.

 

Regards,

 

Connor!

[natew]

Hi

 

Quote:

---

It's perfectly possible to copy the contents of the error folder using Finder or Explorer on Mac 9/X or Windows.

 

 

---

 

The difference is that Retrospect looks at the entire volume as a whole when it runs a backup. The error indicates that two directories on the volume have the same ID. I suspect you would be able to copy them as individual subvolumes in Retrospect too.

 

I've seen this a few times myself and so far I'm pretty sure its not a Retrospect bug. In my experience it happens most often on volumes that emulate AFP like netatalk and NT services for mac. The real bummer is that utilities don't work well/at all on those volumes so you manually have to seek out the problem folders and recreate them.

 

Thanks

Nate

[cpmoran]

Hi Nate,

 

Quote: "The difference is that Retrospect looks at the entire volume as a whole when it runs a backup."

 

Why? Our client's don't want it to be any smarter/dumber than Finder - copy the damn files, that's it.

 

Quote: "...you manually have to seek out the problem folders and recreate them"

 

This morning our client had something like 5,600 files in about 1,000 directories. Using the manual method we had 18, then 12 then 7 then 3 then 1 folder that would not go away.

 

The major PITA here is the Retro thinks it only has 3Kb to backup for some reason and will not advance further.

 

Nate, I think this problem is real and I'd like to help in getting rid of it. We have upgraded a number of clients to Retro 6/MacOS X to take advantage of faster CD-R/DVD-R equipment, only to strike the problem seemingly repeatedly for a couple of clients.

 

Regards,

 

Connor!

[natew]

Hi

 

I certainly agree it is a real problem. However I doubt that Retrospect is solely to blame. Services for Mac and Netatalk emulate mac filesystems. That emulation is not always perfect.

 

What do you mean by "one folder that would not go away"?

 

Can you do a finder copy of the entire volume exactly as specified in the Retrospect script?

 

Thanks

Nate

[cpmoran]

Hi Nate,

 

> What do you mean by "one folder that would not go away"?

>

 

Well... We'd fix one folder using the manual method and the problem would move to another folder. We tried this 7-8 times and gave up. Retro would always complain about a folder somewhere else in the directory.

 

> Can you do a finder copy of the entire volume exactly as specified in the Retrospect script?

>

 

Yes. I "select all" inside the folder we want and I can copy it to another folder on any of MacOS 9.2, MacOS X 10.3.x or Windows machines without issue.

 

> I doubt that Retrospect is solely to blame.

>

 

This would be impossible to argue with my client. They're reasonably technical, and quite clearly this method of operation never failed with Retro 4.2 and MacOS 9.2. It was only when their aging 16x SCSI CD-R gave up that we moved them to MacOS X, Retro 6 and DVD-R as Retro 4.2 wouldn't work with the DVD-R.

 

Finder can copy the all the files off the mounted volume but Retro 6 chokes. Booting to MacOS 9 & Retro 4.2, even though it can't write to the device, it doesn't complain when we do an Immediate with that volume as the source.

 

Regards,

 

Connor!

[llorenz]

We have exact same problem; Duplicating a volume to a Mac drive from a Windows 2000 server volume, using AFP File Services for Mac. Get duplicate DIRID error message.

 

We had way too many folders to do the recreate folders solution, and so went back to OS 9 / Retro 5.

 

Nate''s suggestion that there ARE duplicate ids makes sense to me; I wonder if there's a way to identify the culprit(s) at the server? We are going to have to solve this, since we won't be able to stay with OS 9 forever...

 

Thanks!!

[cpmoran]

Hi Nate,

 

Where are Dantz upto with this problem? It has not gone away.

 

I previously offered to do any testing you require, and that offer is still open. Logs, debug versions anything to get rid of this serious Retrospect bug.

 

Regards,

 

Connor!

[natew]

Hi

 

For the record this is not a Retrospect bug.

Retrospect mounts every volume as if it were a macintosh running MacOS. This problem never happens when the shared volume is a real mac.

 

Netatalk and Windows servers running services for mac emulate a mac file system. That emulation is not perfect. As a result you can run into problems like this one.

 

On some unix file servers you can turn off the fileID function that causes this problem. I am not aware if this is an option for Windows. If the directory ID problems cannot be resolved on the Windows server you may want to try using an OS9 machine to backup these files. Not an ideal solution by any means but it will work. If disk utilities only worked on services for mac volumes...

 

Thanks

Nate

[cpmoran]

Hi Nate,

 

"For the record this is not a Retrospect bug".

 

With respect Nate, something is going wrong. There is a bug.

 

Retrospect claims it can't backup a file/directory because of a "Duplicate DirID". The error is nonsense.

 

In Finder you can go to this folder and copy the contents to the local Mac with no problem what-so-ever. There is no problem with the folder/file structure on the Windows server for the MacOS X machine's point-of-view. While copying the whole folder to the Mac in Finder it doesn't stop and complain "Duplicate DirID" like Retrospect does.

 

What does Retrospect do differently when copying files? Don't do it - can't Retrospect just the same MacOS X file copy API's like Finder?????

 

We can't go back to MacOS 9, because the device type is not supported by Retro 5.

 

This problem is real, and I'd like to assist Dantz finding it.

 

Regards,

 

Connor!

[CallMeDave]

Quote:

---

 

Our client's don't want it to be any smarter/dumber than Finder - copy the damn files, that's it.

 

 

---

 

Most Retrospect users want the program's ability to match files that have already been backed up against the current selection of files, and to have it copy only files that are either new or have changed. And most users want to be assured that if they need to Restore, all the resulting files will be usable.

 

>Retrospect claims it can't backup a file/directory because of a "Duplicate DirID". The error is nonsense.

 

Non-sense. If the directory _does_ have duplicate DirID entries, then the error is correct. Now, it may be that we wish that Retrospect _could_ in fact backup the file/directory, but it's not untruthful that the program can't deal with the reality of the ID situation.

 

 

 

>>...can't Retrospect just the same MacOS X file copy API's like Finder?????

 

Retrospect does use those API's when it does Duplicate operations. But Backup operations are different, since the files aren't being stored as Finder readable files.

 

What would happen if you tested the same Source that gives you an error on backup to a CD/DVD Backup Set, and instead Duplicated that Source to a defined subvolume on the machine running Retrospect? If that works, perhaps you can then run the Backup locally to the optical disk.

 

Double steps, double times, but if it gets around the errors on the other end it might work.

 

Dave

[aev]

This seems to have been fixed with Mac OS X 10.3.6.

 

If you can confirm or "disconfirm" this please post!

 

-aev-

[uwe.strauss]

We had the same problem after switching from a macos 9 with Retrospect 5 to a macos x 10.3 backup client with Retrospect 6. We daily backup a SFM-Volume on a Windows 2000SP4 server. The volume contains about 40,000 directories an 140,000 files (840Gigs).

 

So I searched some weeks for a solution. Because of the limitations and bugs in SFM (max of 65000 files on a SFM volume, no long filenames, ... ) I installed a trial version of the ExtremeZ-IP File Server (www.grouplogic.com). This is the first and only Windows-based file server that fully supports Mac OS X and offers support for Apple's latest version of the AppleShareIP file sharing protocol (AFP 3.1).

 

No more duplicate dirid errors in Retrospect 6! It works great for us.

 

Regards

 

Uwe Strauss

Admin

 

Thomas & Kurzberg GmbH

Germany

[natew]

Thanks for the info!

 

Nate

[llorenz]

10.3.6 seems to have fixed it here, too. So far we have been able to browse a volume without error, and last night I duplicated 20 GBs to a FW drive from a Win 2000 server without the dirid error.