Jump to content

scanned size of MacOS X volume exceeds disk cap.


Recommended Posts

I just upgraded a MacOS 9 machine to MacOS X. The volume under MacOS 9 scanned and

backed up with no errors. Under MacOS X, I'm getting volume sizes of over 600 GB

(disk is only 73 GB) and in addition I'm seeing "error -21 (unknown)" saying that it

can't find a file. The file shows up under the finder and also from the terminal.

 

Note: after finishing the volume it reports that it had one file and 566 GB remaining.

 

Does anyone know why we're seeing the volume size differences and could it be related

to the "error -21"?

Link to comment
Share on other sites

>I just upgraded a MacOS 9 machine to MacOS X. The volume under MacOS 9 scanned and backed up with no errors.

 

Was that before you installed OS X on it? What type of Backup Set are you writing to?

 

>Under MacOS X, I'm getting volume sizes of over 600 GB (disk is only 73 GB)

 

When are you "getting" this volume size?

 

>and in addition I'm seeing "error -21 (unknown)" saying that it can't find a file. The file shows up under the finder and also from the terminal.

 

Did Retrospect report a path to the file? What is the path?

 

You need to provide clear and complete information when asking for help online. For example:

What version of Mac OS X?

What version of Retrospect?

What backup devices are you using?

What is the exact behavior you are seeing?

What are the exact steps you take that result in the behavior you're seeing?
Link to comment
Share on other sites

>>I just upgraded a MacOS 9 machine to MacOS X. The volume under MacOS 9 scanned and backed up with no errors.

 

>Was that before you installed OS X on it? What type of Backup Set are you writing to?

 

Correct. Tape backup set.

 

>>Under MacOS X, I'm getting volume sizes of over 600 GB (disk is only 73 GB)

 

>When are you "getting" this volume size?

 

I see it both in the "source" window when it's doing the copying of the files

and in the log entry.

 

>>and in addition I'm seeing "error -21 (unknown)" saying that it can't find a file. The file shows up under the finder and also from the terminal.

 

>Did Retrospect report a path to the file? What is the path?

 

The path doesn't seem important it's /disk2/collaborations/tobin/tobin, which

in fact doesn't exist, although /disk2/collaborations/tobin does exist. I can't

see anywhere that it's getting that path from.

 

>You need to provide clear and complete information when asking for help online. For example:

 

* What version of Mac OS X? 10.2.1 on server, 10.2.3 on client

* What version of Retrospect? 5.0.238 server, 5.0.540 client

* What backup devices are you using? DLT7000

* What is the exact behavior you are seeing?

As I said the client seems to backup okay, but it leaves "566 GB"

remaining in one file on a 73 GB disk. I've ran disk utilities

on the volume but it passes with no issues. Other MacOS X

machines seem to back up fine.

* What are the exact steps you take that result in the behavior you're seeing?

We had a G3 beige machine running MacOS 9.2.2 with two disks: 6 GB

IDE and 73 GB SCSI. I ran the installer for MacOS X and installed

the OS to the 6 GB disk. The installation went fine. I then

updated MacOS X to the latest release (10.2.3) using software update,

installed the Retrospect client and then added the host to our client

database on the backup server. I saw Retrospect calculate the wrong

size for the volume almost immediately as backup server did that

machine first after it was restarted. The "error -21" entry was in

the log about the same time as the copying started. It probably

was generated during Retrospect scanning the volume.

 

I've searched the knowledgebase and online forums. We had earlier

experienced the windows "finder.dat" issue which seemed similar,

but this is MacOS X now windows. As to the "error -21" issue, so

far all my searches have resulted in zilch, so I'm not certain how

to proceed.

Link to comment
Share on other sites

Quote:

We had a G3 beige machine running MacOS 9.2.2 with two disks: 6 GB IDE and 73 GB SCSI. I ran the installer for MacOS X and installed the OS to the 6 GB disk. The installation went fine. I then updated MacOS X to the latest release (10.2.3) using software update, installed the Retrospect client and then added the host to our client database on the backup server. I saw Retrospect calculate the wrong size for the volume almost immediately as backup server did that machine first after it was restarted.

 

 


 

 

>The path doesn't seem important it's /disk2/collaborations/tobin/tobin, which in fact doesn't exist, although /disk2/collaborations/tobin does exist.

 

It seems pretty important to me that Retrospect is reporting on a path that does not exist (note that "/disk2/collaborations/tobin" describes a the path to a file; if it's a directory it would be "/disk2/collaboratins/tobin/" )

 

I'd suggest first scanning the Volumes one at a time, from Configure->Volumes->Browse

 

From the Browser window you can use the Get Info command (in the File menu) to get specific information for folders and files. You can change the View Options to sort by size, for example, and see if you see something odd.

 

What do you see when you Browse /disk2/collaborations/ ?

 

Dave

 

 

 

Link to comment
Share on other sites

> What do you see when you Browse /disk2/collaborations/ ?

 

I see a "." file. When I look within the finder on MacOS X, it doesn't

show up. However, when I look within a terminal window and do an

"ls -a" I see two "." files.

 

e.g.: . . ..

 

The "." under UNIX represents the current directory which "sort of"

explains by retrospect saw .../tobin/tobin. It is most likely programed

to ignore the first occurance of "." and ".." and then tried to interpret

the 2nd "." as the directory itself, hence ../tobin/tobin.

 

My attempts to clear this was yet another adventure. I first moved

all the other files to another directory and then tried to delete the

tobin directory from within the finder but it failed with an error

"tobin in use". Then I tried "rm -rf tobin" under the terminal

window, but it came back with a message that the request failed

since the directory was not empty. I search the Dantz site and

did a web search but was not able to find any references to

this behavior.

 

Finally, I rebooted into MacOS 9 and was then able to delete

that directory without a problem. After rebooting back into

MacOS X, I instructed retrospect to do another backup. This

time it is giving the correct volume size and NO errors when

scanning the volume.

 

Thanks for the assist. Any idea how this occured?

 

Link to comment
Share on other sites

Quote:

Any idea how this occured?

 


 

Sure, OS 9 allowed a file or folder to be named "."

 

This is a big no-no in unix, and Retrospect is operating properly when running in OS X.

 

The newest Apple Macintosh computers will not boot into OS 9, and as such will not be able to create such files or folders (or allow for their removal using the method you found). Supporting the legacy of OS 9 may be troubling in the near future...

 

Dave

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...