Jump to content
Stevek44

Exhausted inbuf

Recommended Posts

My logs on every operation, backup or restore, has multiple lines of "convertUTF16toUTF32: exhausted inbuf". They do not show up in any Error Reports and everything seems to backup and restore correctly. This seems to have started since I updated to the latest version on Monday.

 

This is on an Xserv PPC running 10.5.8. Backing up Xserv drives to firewire attached LaCie drives.

 

Is this anything to be concerned about other than making my logs larger?

 

Thanks

Share this post


Link to post
Share on other sites

I'm seeing the same message as well, without any additional information on other operations, unfortunately. I had one backup interrupted, but nothing was written to the log detailing what the interruption was, so I'm hoping I'll at least get some details when the current job finishes (provided it's not all interrupted by a power outage - ah, the joys of fall...).

 

I expected that the message:

 

convertUTF16toUTF32: exhausted inbuf

 

meant that the old PowerPC I'm using as the backup server engine machine is just too slow to do the conversion quickly enough to feed the tape library I'm using. Would that log message detail such a case?

 

Thanks.

Share this post


Link to post
Share on other sites
I expected that the message:

 

convertUTF16toUTF32: exhausted inbuf

 

meant that the old PowerPC I'm using as the backup server engine machine is just too slow to do the conversion quickly enough to feed the tape library I'm using. Would that log message detail such a case?

No, I don't think that that is the cause of this error message.

 

I suspect, from the name of the routine that is posting the message, that it's a byte-swapping routine for the PPC that is converting filenames into a uniform format for storage in the catalog. Remember, the media sets now have cross-platform portability with Retrospect for Windows, so the filenames have to support the greatest common denominator. See:

FAQ - UTF-8, UTF-16, UTF-32 and BOM

 

This might just be vestigial debugging code, announcing that the routine has completed its job of converting its UTF-16 input string to UTF-32 without crashing (what a miracle! ready for release!). If there had been adequate Software QA performed on the release, such a message would have been flagged and eliminated (or the cause fixed, if it is an assert error). Sigh. Where is Amy Jensen when she is needed? (oh, having babies):

Amy Jensen's blog

 

Russ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×