As a footnote: I have fixed the problem by converting all the non-UTF8 filenames to UTF8. I discovered a neat little Linux program called "convmv" which does this automatically.
Steve On 5 Jan 2008, at 21:29, Dan Langille wrote: > 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
