On 3/12/2009 11:09 AM, Jerome Alet wrote:
> On Thu, Dec 03, 2009 at 10:54:07AM +0800, Craig Ringer wrote:
>>
>> Anyway, it'd be nice if Bacula would convert file names to utf-8 at the
>> file daemon, using the encoding of the client, for storage in a utf-8
>> database.
>
> +1 for me.
>
> this is the way to go.
>
> I understand people with an existing backup history won't be very happy
> with this unless you provide them the appropriate tools or instructions
> to convert their database's content, though.
I just noticed, while reading src/cats/create_postgresql_database:
# use SQL_ASCII to be able to put any filename into
# the database even those created with unusual character sets
ENCODING="ENCODING 'SQL_ASCII'"
# use UTF8 if you are using standard Unix/Linux LANG specifications
# that use UTF8 -- this is normally the default and *should* be
# your standard. Bacula works correctly *only* with correct UTF8.
#
# Note, with this encoding, if you have any "weird" filenames on
# your system (names generated from Win32 or Mac OS), you may
# get Bacula batch insert failures.
#
#ENCODING="ENCODING 'UTF8'"
... so it's defaulting to SQL_ASCII, but actually supports utf-8 if your
systems are all in a utf-8 locale. Assuming there's some way for the
filed to find out the encoding of the director's database, it probably
wouldn't be too tricky to convert non-matching file names to the
director's encoding in the fd (when the director's encoding isn't
SQL_ASCII, of course).
This also makes me wonder how filenames on Mac OS X and Windows are
handled. I didn't see any use of the unicode-form APIs or any UTF-16 to
UTF-8 conversion in an admittedly _very_ quick glance at the filed/
sources. How does bacula handle file names on those platforms? Read them
with the non-unicode APIs and hope they fit into the current non-unicode
encoding? Or am I missing something?
--
Craig Ringer
