I've included below the relevant part of the Retrospect 4.2 User's Guide
that discusses the Finder.Dat file and gives some background on what happens
when a Mac file is copied to a PC. This has also been added to the
Knowledgebase (this resource is *always* growing, and feedback is

This feature exists in Retrospect to allow you to duplicate a file from a
Mac to a PC, and then to duplicate it back without losing any component of
that file; in this way Retrospect compensates for the differences in how the
two operating systems see files and their attributes.

Not all Mac files are dual-fork, which likely explains why you don't get the
message on all files.


Irena Solomon
Dantz Technical Support

>From p. 99, Retrospect 4.2 User's Guide:

Unlike files on Windows volumes, many Macintosh files are made up of two
parts, called forks: one fork includes data and the other includes
resources. When Retrospect copies a dual-fork Macintosh file to a Windows
client volume, it takes the following steps to separate the forks into
different files.

- It stores the data fork in a new file, which has the same name as the
original file.

- It creates a new folder named Resource.Frk, which is hidden and resides in
the same folder path as the data fork file.

- It stores the resource fork in a new file which resides in the
Resource.Frk folder and has the same name as the original file.

- It tracks fork-separated files in a hidden file named Finder.Dat, which
resides in the same folder path as the data fork file.

If you move one of these Macintosh files on a Windows computer, it is
unusable unless you also move the other files and folder. When you use a
Retrospect Browser to view a Windows client volume containing these split
Macintosh files, only a single file appears. When viewed from Windows, the
extra files appear (unless Windows is set to hide hidden files). When you
back up the files to a backup set or duplicate them to a Macintosh volume,
Retrospect integrates them into the single original file.

> From: Steve Maser <[EMAIL PROTECTED]>
> Subject: The "FINDER.DAT" bug with Retro 4.3
> Hi all,
> I've been able to see this one in action.  It's something you
> might want to be aware of.
> If a user puts a PC-formatted ZIP disk into a Mac, the invisible
> file "finder.dat" is created on the disk (as normal).  Other
> invisible folders are created, but they aren't a problem.
> If the user then puts the disk back into the PC and copies the
> *entire contents* of the disk to the hard disk of the PC, then the
> following happens:
> Because the file "finder.dat" is present on the PC hard disk,
> Retrospect 4.3 will indicate that *some* (but not necessarily *all*)
> other files within that folder are "error -43 -- file/folder not
> found".
> And *some -- but, again, not necessarily all -- subfolders* within
> that folder are skipped by Retrospect, too.
> The only workaround I've found is to be sure that all copies of
> "finder.dat" are deleted from the hard drive.  Retrospect does not
> see the "finder.dat" files when it scans the hard drives, so it can't
> be marked out from a selector to address the problem -- unfortunately.
> According to a tech I talked to at Dantz, "this problem has been
> around for awhile" -- but it's not on the knowledgebase.
> The only solution is to delete all copies of "finder.dat" from the
> PC.  The tech suggested "trying the Windows product".  He didn't know
> if this was going to be a problem with the OSX version of Retrospect.
> FYI...
> - Steve

To subscribe:    [EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:        <http://list.working-dogs.com/lists/retro-talk/>
Search:  <http://www.mail-archive.com/retro-talk%40latchkey.com/>

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Reply via email to