Stephen Winnall wrote: > On 5 Jan 2008, at 16:03, Dan Langille wrote: >> I have confirmed a bug: the job silently fails without reporting the >> following error, which is logged in /var/log/messages: >> >> ERROR: invalid byte sequence for encoding "UTF8": 0x9f >> HINT: This error can also happen if the byte sequence does not >> match the encoding expected by the server is controlled by >> "client_encoding". >> >> No entries are added to the file table. The error should be logged >> and the backup at least not flagged as OK. >> >> As for your situation, there are two questions remaining: >> >> - is the file name valid UTF8? >> - if it is, I wonder if we need to do a "set client_encoding >> 'utf-8'" first > > The filename is not valid UTF8: it is MacRoman created by an old > version of Netatalk which I no longer have in operation: modern > Netatalks create UTF8 filenames which cause no problems
OK, then you need to use SQL_ASCII > As a user, I would prefer Bacula to set client_encoding automatically > from the encoding of the SQL database and to flag filenames which do > not conform to that encoding. I theorize that that is the current default action. From what I've seen, the test results do not conflict with that theory. Correction of this theory is welcome. FWIW, I grep'd the code and did not find any reference to client_encoding. If someone else finds it, please point it out to me. Have a read of this http://www.postgresql.org/docs/8.2/interactive/multibyte.html Especially: 21.2.3. Automatic Character Set Conversion Between Server and Client While working on Phorum (http://www.phorum.org/), I've seen that project allow for a configuration setting for the character set. It would be easy to add to Bacula on a per-catalog basis I think. But we should discuss that in a new thread. > Perhaps the user should be allowed to > decide whether the flag causes a warning (i.e. the file is skipped) or > a fatal error (i.e. Bacula stops) with a message text along the lines > of "filename encoding should be XXX but isn't - please fix the > filename or change the encoding of the Bacula database". That's a good idea. And a feature request, which means another thread. > However, I think there should also be an optional setting specified > which switches off all checking of filename conformity (SQL_ASCII, as > mentioned by Eric, perhaps?), which could be the recommended default. > Bacula should back up anything, I think, and leave the checking of the > filename encoding to other tools. This issue is not Bacula specific. This is a database issue. PostgreSQL is rejecting the data. Not Bacula. Your problem can be quickly resolved by going to an SQL_ASCII encoding for your Bacula database: createdb bacula -E SQL_ASCII But read this first: http://www.bacula.org/dev-manual/Installi_Configur_PostgreS.html There has been much talk about this topic on the lists. Search for "bacula SQL_ASCII". Pay special attention to posts by Kern Sibbald. -- Dan Langille - http://www.langille.org/ BSDCan - The Technical BSD Conference: http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
