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.
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 ...)
