From: | "Kern Sibbald" <kern(at)sibbald(dot)com> |
---|---|
To: | "Avi Rozen" <avi(dot)rozen(at)gmail(dot)com> |
Cc: | "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>, "bacula-devel" <bacula-devel(at)lists(dot)sourceforge(dot)net>, pgsql-general(at)postgresql(dot)org, "bacula-users" <bacula-users(at)lists(dot)sourceforge(dot)net> |
Subject: | Re: [Bacula-users] Catastrophic changes to PostgreSQL 8.4 |
Date: | 2009-12-03 11:22:50 |
Message-ID: | 49189.195.65.96.105.1259839370.squirrel@www.sibbald.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> Craig Ringer wrote:
>> Kern Sibbald wrote:
>>
>>> Hello,
>>>
>>> Thanks for all the answers; I am a bit overwhelmed by the number, so I
>>> am
>>> going to try to answer everyone in one email.
>>>
>>> The first thing to understand is that it is *impossible* to know what
>>> the
>>> encoding is on the client machine (FD -- or File daemon). On say a
>>> Unix/Linux system, the user could create filenames with non-UTF-8 then
>>> switch
>>> to UTF-8, or restore files that were tarred on Windows or on Mac, or
>>> simply
>>> copy a Mac directory. Finally, using system calls to create a file,
>>> you can
>>> put *any* character into a filename.
>>>
>>
>> While true in theory, in practice it's pretty unusual to have filenames
>> encoded with an encoding other than the system LC_CTYPE on a modern
>> UNIX/Linux/BSD machine.
>>
>
> In my case garbage filenames are all too common. It's a the sad
> *reality*, when you're mixing languages (Hebrew and English in my case)
> and operating systems. Garbage filenames are everywhere: directories and
> files shared between different operating systems and file systems, mail
> attachments, mp3 file names based on garbage id3 tags, files in zip
> archives (which seem to not handle filename encoding at all), etc.
Yes, that is my experience too. I understand Craig's comments, but I
would much prefer that Bacula just backup and restore and leave the
checking of filename consistencies to other programs. At least for the
moment, that seems to work quite well. Obviously if users mix character
sets, sometime display of filenames in Bacula will be wierd, but
nevertheless Bacula will backup and restore them so that what was on the
system before the backup is what is restored.
>
> When I first tried Bacula (version 1.38), I expected to have trouble
> with filenames, since this is what I'm used to. I was rather pleased to
> find out that it could both backup and restore files, regardless of
> origin and destination filename encoding.
>
> I like Bacula because, among other things, it can take the punishment
> and chug along, without me even noticing that there was supposed to be a
> problem (a recent example: backup/restore files with a negative mtime ...)
>
Thanks. Thanks also for using Bacula :-)
Best regards,
Kern
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2009-12-03 11:32:38 | Re: Catastrophic changes to PostgreSQL 8.4 |
Previous Message | Daniel Verite | 2009-12-03 11:18:31 | Re: Catastrophic changes to PostgreSQL 8.4 |
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2009-12-03 11:32:38 | Re: Catastrophic changes to PostgreSQL 8.4 |
Previous Message | Daniel Verite | 2009-12-03 11:18:31 | Re: Catastrophic changes to PostgreSQL 8.4 |