Maser Posted October 11, 2002 Report Share Posted October 11, 2002 I've needed to revert back to 5.0.205 from 5.0.236 because a large number of Windows Clients (running 6.0) are reporting individual files as beeing many hundreds of Gigs when, in fact, they are very tiny files (ie, 12-60K word docs) Reverting back to 5.0.205 (still under 10.2.1 now), is showing the files with their correct size *and* backing them up -- which is the critical thing. 5.0236 would not back up those files (it's giving error -39). What's the status of this issue? (And how could it slip past Q/A? All 3 of my machines backing up Windows clients (98/ME/NT/2000/XP) are showing this. Link to comment Share on other sites More sharing options...
Mayoff Posted October 11, 2002 Report Share Posted October 11, 2002 We are aware of this problem and we are investigating. We have found that for some users the problem is just cosmetic. If you back up to a tape drive, you may be able to successfully back up. Link to comment Share on other sites More sharing options...
Maser Posted October 11, 2002 Author Report Share Posted October 11, 2002 I back up to DLT. 5.0.236 is not backing up the "wrongly sized" files in question. Reverting back to 5.0205 backed them up. So -- for me -- it's more than just cosmetic (probably because the actual file size scanned is different than what it *thinks* the file size is when the backup hits it...) I need the fixes in 5.0.236 (particularly the memory issue in Backup Server mode), but I need to be assured that the files on Windows machines are getting backed up. Link to comment Share on other sites More sharing options...
Mayoff Posted October 11, 2002 Report Share Posted October 11, 2002 Check the Windows disk for finder.dat files. These files are probably "orphans" and can be deleted. Once you have done that on the PC, the problem will probably go away. Link to comment Share on other sites More sharing options...
Maser Posted October 14, 2002 Author Report Share Posted October 14, 2002 Can "finder.dat" be added to an "exempt" selector and have this problem go away? Or do the Windows clients need to purge these files before the reporting will be correct? Thanks! Link to comment Share on other sites More sharing options...
Mayoff Posted October 14, 2002 Report Share Posted October 14, 2002 orphaned Finder.dat files are not visible in a Retrospect Browser and would need to be removed from the PC directly prior to a backup attempt. Link to comment Share on other sites More sharing options...
Maser Posted October 14, 2002 Author Report Share Posted October 14, 2002 so: will there be another update to Retro 5 that will rever things back to 5.0.205 behavior when it comes to dealing with these files? Or will the only option be to scrap the finder.dat files? Link to comment Share on other sites More sharing options...
Maser Posted October 14, 2002 Author Report Share Posted October 14, 2002 The reason I bring this up: A user could *now* kill his "finder.dat" files, but there's nothing to prevent this from happening in the future. There needs to be a mechanism -- like there seemed to be in 5.0205 -- that overlooks these files. Or was it that 5.0.205 just skipped everything without reporting errors? Link to comment Share on other sites More sharing options...
den5769 Posted October 15, 2002 Report Share Posted October 15, 2002 I am having a similar problem! I have one WinXP box in an office of Macs that mainly runs Peachtree accounting software, which uses .dat files to store data. Retrospect 5.0.236 incorrectly shows them (7 files) as being 337.8GB each! I have tried both the 6.0 and 5.6 clients and each operates the same. I can't "delete" these files because they are required. It does seem to copy Peachtree backup files (.ptb) correctly, so I have the user run this backup so we have the data in some workable format. This is the only a workaround and a patch needs to be posted ASAP! Link to comment Share on other sites More sharing options...
brising Posted October 22, 2002 Report Share Posted October 22, 2002 I think the problem is worse than just .dat files. I'm getting gazillions of errors from one of the Windows users for files with any suffix of .pre .uniq plus some other files where the extension does not seem to be the problem. All the files are in subdirectories off a single directory, so perhaps the problem both one of the directory as well as the files it contains. Bill Link to comment Share on other sites More sharing options...
CallMeDave Posted October 22, 2002 Report Share Posted October 22, 2002 In reply to: I think the problem is worse than just .dat files The problem is not with ".dat" files. The problem is with one particular file, named "Finder.dat" and only in certain situations. >>I'm getting gazillions of errors from one of the Windows users What are the errors? >>All the files are in subdirectories off a single directory, so perhaps the problem both one of the directory as well as the files it contains. Excellent theory. Does this directory contain a file named "Finder.dat"? (note: you'll have to look from within Windows; the Retrospect Browser window will not display it if it's there) Dave Link to comment Share on other sites More sharing options...
brising Posted October 23, 2002 Report Share Posted October 23, 2002 In reply to: >>I'm getting gazillions of errors from one of the Windows users What are the errors? error -39 (unexpected end of file) In reply to: >>All the files are in subdirectories off a single directory, so perhaps the problem both one of the directory as well as the files it contains. Excellent theory. Does this directory contain a file named "Finder.dat"? (note: you'll have to look from within Windows; the Retrospect Browser window will not display it if it's there) All of the directories contain a Finder.dat file. Here's a wild guess: Retrospect sees the Finder.dat file, goes looking for resource forks, which don't exist on the Windows machine, and gets itself all confused. I'm guessing this because _Icon files have troubles, files with particular names have troubles, yet some files within the directories back up just fine. I'm guessing that the files which have no trouble are files which would have no resource forks on a Mac. Of course, this guess is based on zero knowledge of what is in a Finder.dat file, and zero knowledge of what happens when a Mac file with a resource fork is copied off a zip disk onto a Windows machine. Bill Link to comment Share on other sites More sharing options...
Maser Posted October 23, 2002 Author Report Share Posted October 23, 2002 Bottom line: Why was this *not* an issue in 5.0.205, but is now and issue in 5.0.236? And will there be a patch (soon?) that addresses this? Or will there be no patch? Nobody has said anything about a patch for this specific problem on the board... - Steve Link to comment Share on other sites More sharing options...
ricwash Posted October 30, 2002 Report Share Posted October 30, 2002 I have just done a complete check of the windows client...there are no "finder.dat" files, yet the retrospect program still says there is 1011G to backup when there is only about 22G of data on the drive. Also, I get about 75K lines of -39 errors. -Ric Link to comment Share on other sites More sharing options...
Sridar Posted October 30, 2002 Report Share Posted October 30, 2002 This problem is not just cosmetic. I back up a particular WinXP user's laptop to hard disk, and the backup fails (insufficient space) when Retrospect thinks it needs > 400GB of space. Reverting to build 205 fixes this problem, but returns the old problems of that build (broken RetroRun in particular). What's the time frame for the patch? Link to comment Share on other sites More sharing options...
CallMeDave Posted October 30, 2002 Report Share Posted October 30, 2002 In reply to: This problem is not just cosmetic I don't think anyone has suggested that it is. But the problem _is_ easily avoided for now. Just delete the finder.dat files, that were probably copied unnecessarily onto the Windows machine. Dave Link to comment Share on other sites More sharing options...
ricwash Posted October 30, 2002 Report Share Posted October 30, 2002 In Reply to: But the problem _is_ easily avoided for now. Just delete the finder.dat files, that were probably copied unnecessarily onto the Windows machine. But as I stated in a posting I don't have any finder.dat files, but I still have a problem... -Ric Link to comment Share on other sites More sharing options...
Sridar Posted October 31, 2002 Report Share Posted October 31, 2002 Unfortunately, I am in the same boat as Ric. A search for "Finder.dat" or "finder.dat" on the Win XP laptop (using the search in WinXP, not through Retrospect) does not turn up any hits. Any suggestions? Thanks, Sridar Link to comment Share on other sites More sharing options...
CallMeDave Posted October 31, 2002 Report Share Posted October 31, 2002 >>A search for "Finder.dat" or "finder.dat" on the Win XP laptop >>(using the search in WinXP, ...) does not turn up any hits. Unless you have Windows configured to show invisible files, a search won't turn up Finder.dat files. Dave Link to comment Share on other sites More sharing options...
Sridar Posted October 31, 2002 Report Share Posted October 31, 2002 If I recall, MacOS puts the "FINDER.DAT" file on a DOS disk (usually a floppy) when copying files with names longer than 8.3. The FINDER.DAT file contains information to reconstruct long (in those days) Mac filenames. Resource forks were stored in a RESOURCE.FRK directory. I'm not sure why Finder.dat files would be popping up now on WinXP systems unless users were using DOS floppies to copy files from an old Mac. They don't seem to be created on our file servers (instead there are files such as .AppleFileInfo and .DS_Store, presumably containing resource fork info). HTH, Sridar Link to comment Share on other sites More sharing options...
Maser Posted November 1, 2002 Author Report Share Posted November 1, 2002 Yeah, it's the "hidden-ness" of these files that bite my users. WinXP has an "advanced" option in the find that you can toggle to search for hidden files. Older versions of windows, you have to go to the View options and hit the button to make all hidden files visible before you can find them. DANTZ: Any word on a patch for this? Link to comment Share on other sites More sharing options...
pnorton Posted November 12, 2002 Report Share Posted November 12, 2002 Until there is a fix from Dantz, the easiest way to deal with the problem is to make a custom selector that does not backup files larger than your storage media, or say 2GB. I had the same problem, with a Win2000 machine with two supposedly 360GB files. The files were actually 1k, but I just created a selector that ignored files larger than 2GB, added to the scripts that backup PCs, and now I don't have a problem. Link to comment Share on other sites More sharing options...
Maser Posted November 12, 2002 Author Report Share Posted November 12, 2002 That may work. I'd have to check into it. DANTZ: Does the just-released 5.0.238 version address this problem? The release notes seem to not say so (but it apparently mentions some -43 errors should be "less"). Link to comment Share on other sites More sharing options...
michaelcutter Posted November 22, 2002 Report Share Posted November 22, 2002 Hi all, this problem is still happening (as I have just discovered for the first time) using 5.238 Server on OS X 10.2.2 and 6.0.11 on the Windows client. 5 files, all excel spreadsheets, all 3.0Gb in size according to Retrospect. I'm not at work so I can't check how big they really are, but this is an unacceptable issue, when is it going to be resolved, Dantz? Cheers, Mike Link to comment Share on other sites More sharing options...
AmyJ Posted November 22, 2002 Report Share Posted November 22, 2002 We are working on it and will post a fix when it becomes available. For the time being, delete any Finder.dat files on your Windows system. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.