Jump to content

Exhausted inbuf


Stevek44

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

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...