From: Craig B. <cba...@us...> - 2006-07-13 06:58:38
|
I have released BackupPC 3.0.0beta0 on SF at: http://backuppc.sourceforge.net/ =20 A new version 0.62 of File::RsyncP that is needed for rsync hardlink support has also been released on SF and CPAN. 3.0.0beta0 has some substantial new features compared to 2.1.2. New features include: * Added configuration and host CGI editor. * Added rsync hardlink support. Requires latest version of File::RsyncP (0.62). * Decoupled BackupPC_dump from BackupPC_nightly by making asynchronous file linking/delete robust to race conditions. Now only BackupPC_nightly and BackupPC_link are mutually exclusive so only one runs at a time, and BackupPC_dump and BackupPC_restore can run anytime. * Added support for multi-level incrementals. In the style of dump(1), the level of each incremental can be specified. Each incremental backups up everything since the most recent backup of a lower level (fulls are always level 0). Previous behavior was all incrementals were level 1, meaning they backed up everything since the last full (level 0). Default configuration is all incrementals are level 1. * Server file names are now in utf8 and optional conversion to/from client name charsets can be configured. All CGI pages now use the utf8 charset. * Added RSS support from Rich Duzenbury. * Added optional checking of exit status of Dump/Restore/Archive Pre/Post= UserCmd. * For new installations configure.pl places all the configuration files below /etc/BackupPC, bringing it more in line with the File System Hierarchy Standard (FHS). See the ChangeLog for full details. Depending upon the reported bugs and issues there could be additional patches and beta releases prior to the offical 3.0.0 release. Enjoy! Craig |
From: Guillaume F. <gf...@lo...> - 2006-07-13 23:27:08
Attachments:
PGP.sig
|
Le 06-07-13, =E0 02:58, Craig Barratt a =E9crit : > I have released BackupPC 3.0.0beta0 on SF at: > > http://backuppc.sourceforge.net/ > > A new version 0.62 of File::RsyncP that is needed for rsync > hardlink support has also been released on SF and CPAN. I'm getting this error when trying to upgrade to File::RsyncP 0.62=20 using CPAN.pm: cc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN=20 -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE=20 -D_FILE_OFFSET_BITS=3D64 -O2 -DVERSION=3D\"0.62\" = -DXS_VERSION=3D\"0.62\"=20 -fPIC "-I/usr/lib/perl/5.8/CORE" -DPERL_BYTEORDER=3D FileList.c FileList.xs: In function 'getHashString': FileList.xs:64: warning: pointer targets in passing argument 3 of=20 'Perl_sv_2pv_flags' differ in signedness FileList.c: In function 'XS_File__RsyncP__FileList_exclude_check': FileList.c:713: warning: pointer targets in initialization differ in=20 signedness FileList.c: In function 'XS_File__RsyncP__FileList_exclude_add': FileList.c:747: warning: pointer targets in initialization differ in=20 signedness FileList.c: In function 'XS_File__RsyncP__FileList_exclude_add_file': FileList.c:778: warning: pointer targets in initialization differ in=20 signedness cc -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN=20 -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE=20 -D_FILE_OFFSET_BITS=3D64 -O2 -DVERSION=3D\"0.62\" = -DXS_VERSION=3D\"0.62\"=20 -fPIC "-I/usr/lib/perl/5.8/CORE" -DPERL_BYTEORDER=3D exclude.c exclude.c:29: error: static declaration of 'verbose' follows non-static=20= declaration rsync.h:811: error: previous declaration of 'verbose' was here exclude.c: In function 'get_exclude_tok': exclude.c:262: warning: pointer targets in passing argument 1 of=20 'strlen' differ in signedness make[1]: *** [exclude.o] Error 1 make[1]: Leaving directory `/root/.cpan/build/File-RsyncP-0.62/FileList' make: *** [subdirs] Error 2 Keep up the good work, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Guillaume F. <gf...@lo...> - 2006-07-13 23:41:25
Attachments:
PGP.sig
|
Le 06-07-13, =E0 19:26, Guillaume Filion a =E9crit : > Le 06-07-13, =E0 02:58, Craig Barratt a =E9crit : >> A new version 0.62 of File::RsyncP that is needed for rsync >> hardlink support has also been released on SF and CPAN. > > I'm getting this error when trying to upgrade to File::RsyncP 0.62=20 > using CPAN.pm: This seems to solve the problem: gfk@ali:~/backuppc/File-RsyncP-0.62/FileList$ diff -u exclude.c.org=20 exclude.c --- exclude.c.org 2006-07-13 19:39:21.000000000 -0400 +++ exclude.c 2006-07-13 19:37:27.000000000 -0400 @@ -26,7 +26,7 @@ #include "rsync.h" -static int verbose; +int verbose; /** Build an exclude structure given an exclude pattern. */ static void make_exclude(struct file_list *f, struct=20 exclude_list_struct *listp, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-15 22:16:42
|
Guillaume Filion writes: > Le 06-07-13, =E0 19:26, Guillaume Filion a =E9crit : > > Le 06-07-13, =E0 02:58, Craig Barratt a =E9crit : > >> A new version 0.62 of File::RsyncP that is needed for rsync > >> hardlink support has also been released on SF and CPAN. > > > > I'm getting this error when trying to upgrade to File::RsyncP 0.62=20 > > using CPAN.pm: >=20 > This seems to solve the problem: >=20 > gfk@ali:~/backuppc/File-RsyncP-0.62/FileList$ diff -u exclude.c.org=20 > exclude.c > --- exclude.c.org 2006-07-13 19:39:21.000000000 -0400 > +++ exclude.c 2006-07-13 19:37:27.000000000 -0400 > @@ -26,7 +26,7 @@ >=20 > #include "rsync.h" >=20 > -static int verbose; > +int verbose; >=20 > /** Build an exclude structure given an exclude pattern. */ > static void make_exclude(struct file_list *f, struct=20 > exclude_list_struct *listp, Thanks. I'll wait a week or two in case other bugs are reported and then I'll do another release. BTW, what compiler are you using? With gcc 3.4.x it builds cleanly for me on two different platforms. Craig |
From: Guillaume F. <gf...@lo...> - 2006-07-16 01:21:36
|
Le 06-07-15, à 18:16, Craig Barratt a écrit : > BTW, what compiler are you using? With gcc 3.4.x it builds > cleanly for me on two different platforms. I'm running the compiler that comes with debian testing (linux-2.4.27-2-k7): gfk@ali:~$ gcc --version gcc (GCC) 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) I included my full make log -- with and without my mini patch applied. Best, GFK's -- Guillaume Filion, ing. jr Logidac Tech., Beaumont, Québec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Nicolas S. <Ni...@ne...> - 2006-07-16 00:20:34
Attachments:
fr.pm.diff
|
Hi Craig, Here is a patch for fr.pm that corrects a few minor typos. This is against version 1.47 from CVS. Regards, -- Nico Les femmes ont plus de honte de confesser une chose d'amour que de la faire. -+- Marguerite De Navarre -+- |
From: Guillaume F. <gf...@lo...> - 2006-07-20 22:32:48
Attachments:
PGP.sig
|
Le 06-07-15, =E0 20:20, Nicolas STRANSKY a =E9crit : > Here is a patch for fr.pm that corrects a few minor typos. This is > against version 1.47 from CVS. Merci, I commited it. Checking in fr.pm; /cvsroot/backuppc/BackupPC/lib/BackupPC/Lang/fr.pm,v <-- fr.pm new revision: 1.48; previous revision: 1.47 done Regards, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Guillaume F. <gf...@lo...> - 2006-07-20 17:32:40
Attachments:
signature.asc
|
Craig Barratt a =E9crit : > I have released BackupPC 3.0.0beta0 on SF at: Here's a change in behavior that I noted from 2.1.2: For SMB hosts with uppercase letters in their name in the hosts file (Administration vs administration): -in 2.1.2, BackupPC would convert that name to all lowercase letters. -in 3.0.x, BackupPC does not convert the case and complains that the host has never been backed up and that there's a Netbios name mismatch. I'm not sure if it's really a big or just an annoyance, on the other hand I was able to use the CGI Editor to rename the hosts with uppercase letters in their names. :-) Best, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-22 23:58:58
|
Guillaume Filion writes: > Craig Barratt a =E9crit : > > > I have released BackupPC 3.0.0beta0 on SF at: >=20 > Here's a change in behavior that I noted from 2.1.2: >=20 > For SMB hosts with uppercase letters in their name in the hosts file > (Administration vs administration): >=20 > -in 2.1.2, BackupPC would convert that name to all lowercase letters. > -in 3.0.x, BackupPC does not convert the case and complains that the > host has never been backed up and that there's a Netbios name mismatch.= >=20 > I'm not sure if it's really a big or just an annoyance, on the other > hand I was able to use the CGI Editor to rename the hosts with uppercas= e > letters in their names. :-) That's a good point. I did make that change since I thought if the user put a mixed-case host name in the hosts file, it is strange for that host to appear in the CGI and $TOPDIR/pc in lower case. I'm wondering if that's still a good idea. This does create a risk of incompatibility after upgrade if someone has mixed-case host names. I should either change it back, or: - change configure.pl to make all the host names lower case during upgrade,=20 - make the netbios name check case insensitive (the netbios name is always forced to lower case, but in 3.0.0 the host name is not, so the comparison fails). I'm leaning towards just changing it back. Which way do you recommend? I should look through my email to see what prompted me to change it. Craig |
From: Guillaume F. <gf...@lo...> - 2006-07-23 05:40:39
Attachments:
PGP.sig
|
Le 06-07-22, =E0 19:58, Craig Barratt a =E9crit : > Guillaume Filion writes: >> -in 2.1.2, BackupPC would convert that name to all lowercase letters. >> -in 3.0.x, BackupPC does not convert the case and complains that the >> host has never been backed up and that there's a Netbios name=20 >> mismatch. > > That's a good point. I did make that change since I thought > if the user put a mixed-case host name in the hosts file, it > is strange for that host to appear in the CGI and $TOPDIR/pc > in lower case. > > I'm wondering if that's still a good idea. This does create > a risk of incompatibility after upgrade if someone has mixed-case > host names. > > I should either change it back, or: > > - change configure.pl to make all the host names lower case > during upgrade, A warning in configure.pl and an option/suggestion to convert the host=20= names to lower case would seem like a good option. > - make the netbios name check case insensitive (the netbios name > is always forced to lower case, but in 3.0.0 the host name is > not, so the comparison fails). That wouldn't work since the old backups would be in a directory with=20 only lower case letters (inaccessible from BackupPC) and the new=20 backups would be taken in a directory with capital letters. > I'm leaning towards just changing it back. Which way do you recommend? > I should look through my email to see what prompted me to change it. I'm not sure why you changed it in the first place, so I'm leaning=20 toward changing it back too :-) but if you prefer to put a warning in=20 configure.pl it's fine with me. Best, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-23 06:28:10
|
Guillaume Filion writes: > > > > I should either change it back, or: > > > > - change configure.pl to make all the host names lower case > > during upgrade, >=20 > A warning in configure.pl and an option/suggestion to convert the host=20 > names to lower case would seem like a good option. >=20 > > - make the netbios name check case insensitive (the netbios name > > is always forced to lower case, but in 3.0.0 the host name is > > not, so the comparison fails). >=20 > That wouldn't work since the old backups would be in a directory with=20 > only lower case letters (inaccessible from BackupPC) and the new=20 > backups would be taken in a directory with capital letters. I was meaning do both of the changes. > > I'm leaning towards just changing it back. Which way do you recommend= ? > > I should look through my email to see what prompted me to change it. >=20 > I'm not sure why you changed it in the first place, so I'm leaning=20 > toward changing it back too :-) but if you prefer to put a warning in=20 > configure.pl it's fine with me. I'm going to change it back. I'll add something to the docs. The only email about confusion from forced lower case is attached. Craig ---------- Forwarded message ---------- To: bac...@li... From: alain perrier <ape...@in...> Date: Mon, 20 Dec 2004 18:56:16 +0100 Subj: [BackupPC-users] BUG? archive name with upper case characters Hello, I'm trying to configure an archive device. I have a LTO tape drive=20 attached to my BackupPC host. I created a host "ArchiveLTO", a directory=20 .../pc/ArchiveLTO with TransfertMethode=3D 'archive' and ... BackupPC=20 shown me this device as a PC! I discovered that it don't like my upper=20 case name so I renamed it to "archive-lto" and all works fine! --=20 Alain PERRIER ape...@in... INA - Direction de la Recherche et Exp=E9rimentation 4, Avenue de l'Europe - F-94366 Bry s/Marne Cedex http://www.ina.fr/recherche Tel : 33 (0) 1 49 83 23 86 Fax : 33 (0) 1 49 83 29 29 |
From: Guillaume F. <gf...@lo...> - 2006-07-20 18:47:21
Attachments:
signature.asc
|
Craig Barratt a =E9crit : > * Server file names are now in utf8 and optional conversion > to/from client name charsets can be configured. All CGI pages > now use the utf8 charset. It looks like the lang files are still in iso-latin, I remember that you said that they would be converted by makeDist. I guess the best way of doing that would be to include the charset on top of the lang files, for example: #!/bin/perl #BackupPC-charset=3Diso-8859-1 with something like this in makeDist: my $converter; while ( <FILE> ) { $converter =3D Text::Iconv->new($1, 'utf8') if (/BackupPC-charset=3D([a-z\-0-9]+)/); [...] } elsif ($converter) { print OUT $converter->convert($_); } else { print OUT; } Here's a patch that does this: Index: makeDist =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/backuppc/BackupPC/makeDist,v retrieving revision 1.35 diff -r1.35 makeDist 45a46 > use Text::Iconv; 264a266 > my $converter; 290a293 > $converter =3D Text::Iconv->new($1, 'utf8') if (/BackupPC-charset=3D([a-z\-0-9]+)/); 309a313,314 > } elsif ( $converter ) { > print OUT $converter->convert($_); Best, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-22 23:00:21
|
Guillaume Filion writes: > Craig Barratt a =E9crit : > > * Server file names are now in utf8 and optional conversion > > to/from client name charsets can be configured. All CGI pages > > now use the utf8 charset. >=20 > It looks like the lang files are still in iso-latin, I remember that yo= u > said that they would be converted by makeDist. >=20 > I guess the best way of doing that would be to include the charset on > top of the lang files, for example: I was planning to convert, but I believe it is correct the way it is. Perl parses the language files as iso-latin, and internally converts the strings automatically to utf8 via the utf8 output filter. Do the french strings in 3.0.0beta0 render correctly for you? They do for me. That said, I'm not 100% sure that perl will always default to iso-latin. Perhaps the LANG setting will affect it, or maybe I need to add "no utf8" to all the lang files? I need to look at docs a little more. Craig |
From: Guillaume F. <gf...@lo...> - 2006-07-23 14:53:01
Attachments:
PGP.sig
|
Le 06-07-22, =E0 19:00, Craig Barratt a =E9crit : > Guillaume Filion writes: >> It looks like the lang files are still in iso-latin, I remember that=20= >> you >> said that they would be converted by makeDist. > > I was planning to convert, but I believe it is correct the > way it is. Perl parses the language files as iso-latin, > and internally converts the strings automatically to utf8 > via the utf8 output filter. > > Do the french strings in 3.0.0beta0 render correctly for > you? They do for me. I'm confused... I have two BackupPC servers, one with my patch and one=20= without and both render fine in Safari/OSX. I think that my problem was=20= with Firefox on Windows. Give me some days and I'll try to figure it=20 out. One thing's for sure is that not all languages can be encoded in=20 iso-latin. If you want to have a chinese language file, it will need to=20= be encoded in something other than iso-latin (GB 18030, Big5 or UTF8). Anyway, I'll try to get my head wrap around it... --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-23 15:49:17
|
Guillaume Filion writes: > Le 06-07-22, =E0 19:00, Craig Barratt a =E9crit : > > Guillaume Filion writes: > >> It looks like the lang files are still in iso-latin, I remember that= =20 > >> you > >> said that they would be converted by makeDist. > > > > I was planning to convert, but I believe it is correct the > > way it is. Perl parses the language files as iso-latin, > > and internally converts the strings automatically to utf8 > > via the utf8 output filter. > > > > Do the french strings in 3.0.0beta0 render correctly for > > you? They do for me. >=20 > I'm confused... I have two BackupPC servers, one with my patch and one=20 > without and both render fine in Safari/OSX. I think that my problem was= =20 > with Firefox on Windows. Give me some days and I'll try to figure it=20 > out. I'm using Firefox on Windows and it works for me. But it certainly could be dependent upon perl versions, LANG settings etc. > One thing's for sure is that not all languages can be encoded in=20 > iso-latin. If you want to have a chinese language file, it will need to= =20 > be encoded in something other than iso-latin (GB 18030, Big5 or UTF8). That's right. Those language files should include a "use utf8" declaration and use utf8 literals. That should work seamlessly, since the utf8 output filter will then be a no-op. Perl still defaults to "no utf8" for string literals, but I think it auto-detects wide characters (eg: \x{4321}). I am tempted to add "no utf8" to the language files, since the perl docs imply that in future versions utf8 might be the default. Craig |
From: Klaus W. <Kla...@gm...> - 2006-07-23 16:06:07
|
Hello, I am not sure if I understood the problem right. Is it just problem you hav= e=20 on some systems or browsers how the pages are displayed? Have you thought=20 about that different browsers could have installed different default=20 encodings. As far as I could see on a quick view there gets not character=20 encoding transmitted from BackupPC, so that the browsers default will be us= ed=20 and that could be different from what BackupPC actually sends. Seems there = is=20 no line like "<meta http-equiv=3D"Content-Type" content=3D"text/html;=20 charset=3DUTF-8"/>" in the <head> tag of the html files. Or maybe you can a= lso=20 have a problem that the webserver sends a default encoding that overrides=20 others, like you can configure in Apache2? Just a few thoughts. Maybe it helps. I am looking forward to the next pre releases of BackupPC3.0.0! It looks go= od=20 so far. Regards, Klaus > > > I was planning to convert, but I believe it is correct the > > > way it is. Perl parses the language files as iso-latin, > > > and internally converts the strings automatically to utf8 > > > via the utf8 output filter. > > > > > > Do the french strings in 3.0.0beta0 render correctly for > > > you? They do for me. > > > > I'm confused... I have two BackupPC servers, one with my patch and one > > without and both render fine in Safari/OSX. I think that my problem was > > with Firefox on Windows. Give me some days and I'll try to figure it > > out. > > I'm using Firefox on Windows and it works for me. But it > certainly could be dependent upon perl versions, LANG settings > etc. =2D-=20 take care! xo,klaus |
From: Guillaume F. <gf...@lo...> - 2006-07-26 15:23:56
Attachments:
signature.asc
|
Klaus Weidenbach a =E9crit : > Seems there is=20 > no line like "<meta http-equiv=3D"Content-Type" content=3D"text/html;=20 > charset=3DUTF-8"/>" in the <head> tag of the html files.=20 That's a good hypothesis, but BackupPC sets the charset in the HTTP heade= rs: lib/BackupPC/CGI$ fgrep charset * Lib.pm: print $Cgi->header(-charset =3D> "utf-8"); However, I was able to reproduce the problem I was getting earlier. I reinstalled backuppc from the latest cvs on my two servers -- both running debian testing with perl 5.8.8. One of them (ali) is sending utf8 encoded web pages that render correctly, it has LANG set to "C". The other one (sylvester) is sending web pages encoded in iso-latin-1 but with a utf8 charset HTTP header. The pages don't render correctly unless I change the encoding in Firefox to iso-latin-1. When I browse the backups, the filenames display correctly. It has LANG set to "fr-CA" and my locale is set to "fr_CA ISO-8859-1". I tried setting my locale to nothing, to fr_CA.utf8, setting the env variable LANG=3DC, putting "no utf8;" in the lang files, but I can't get it to work... So after all this, I'm still confused, but not for the same reasons as before... :-( GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-27 14:31:21
|
Guillaume Filion writes: > Klaus Weidenbach a =E9crit : > > Seems there is=20 > > no line like "<meta http-equiv=3D"Content-Type" content=3D"text/html;= =20 > > charset=3DUTF-8"/>" in the <head> tag of the html files.=20 >=20 > That's a good hypothesis, but BackupPC sets the charset in the HTTP hea= ders: > lib/BackupPC/CGI$ fgrep charset * > Lib.pm: print $Cgi->header(-charset =3D> "utf-8"); >=20 > However, I was able to reproduce the problem I was getting earlier. >=20 > I reinstalled backuppc from the latest cvs on my two servers -- both > running debian testing with perl 5.8.8. >=20 > One of them (ali) is sending utf8 encoded web pages that render > correctly, it has LANG set to "C". >=20 > The other one (sylvester) is sending web pages encoded in iso-latin-1 > but with a utf8 charset HTTP header. The pages don't render correctly > unless I change the encoding in Firefox to iso-latin-1. When I browse > the backups, the filenames display correctly. It has LANG set > to "fr-CA" and my locale is set to "fr_CA ISO-8859-1". >=20 > I tried setting my locale to nothing, to fr_CA.utf8, setting the env > variable LANG=3DC, putting "no utf8;" in the lang files, but I can't ge= t > it to work... So after all this, I'm still confused, but not for the > same reasons as before... :-( Interesting. There's something going on we need to understand. What happens when you run this one-liner on your two machines? perl -e 'binmode(STDOUT, ":utf8"); print("\x{e9}");' | od -t x1 This should convert the code point 0xe9 (=E9) to utf8 and print two bytes: c3 a9 You could then try this: perl -e 'binmode(STDOUT, ":utf8"); print("=E9");' | od -t x1 and it should print the same thing. Craig |
From: Guillaume F. <gf...@lo...> - 2006-07-27 18:32:19
Attachments:
signature.asc
|
Craig Barratt a =E9crit : > Interesting. There's something going on we need to understand. >=20 > What happens when you run this one-liner on your two machines? > perl -e 'binmode(STDOUT, ":utf8"); print("\x{e9}");' | od -t x1 > This should convert the code point 0xe9 (=E9) to utf8 and print > two bytes: > c3 a9 > You could then try this: > perl -e 'binmode(STDOUT, ":utf8"); print("=E9");' | od -t x1 > and it should print the same thing. gfk@ali:~$ cat test-utf8.sh #!/bin/sh perl -e 'binmode(STDOUT, ":utf8"); print("\x{e9}");' | od -t x1 perl -e 'binmode(STDOUT, ":utf8"); print("=E9");' | od -t x1 gfk@ali:~$ ./test-utf8.sh 0000000 c3 a9 0000002 0000000 c3 a9 0000002 [...] gfk@sylvester:~$ ./test-utf8.sh 0000000 c3 a9 0000002 0000000 c3 a9 0000002 Mumble mumble... Let's try something else... ----- gfk@sylvester:/www/cgi-bin$ cat test-utf8.pl #!/usr/bin/perl use strict; use CGI qw/:standard/; binmode(STDOUT, ":utf8"); print header(-charset =3D> "utf-8"); print("\x{e9}"); print("=E9"); ----- It shows fine in FireFox and Ethereal shows that c3 a9 are transmitted correctly: 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0a 44 61 74 65 3a 20 54 68 75 2c 20 32 37 20 4a .Date: T hu, 27 J 75 6c 20 32 30 30 36 20 31 37 3a 35 36 3a 30 38 ul 2006 17:56:08 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 GMT..Se rver: Ap 61 63 68 65 2f 31 2e 33 2e 33 34 20 28 44 65 62 ache/1.3 .34 (Deb 69 61 6e 29 20 6d 6f 64 5f 70 65 72 6c 2f 31 2e ian) mod _perl/1. 32 39 0d 0a 4b 65 65 70 2d 41 6c 69 76 65 3a 20 29..Keep -Alive: 74 69 6d 65 6f 75 74 3d 31 35 2c 20 6d 61 78 3d timeout=3D 15, max=3D 31 30 30 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a 100..Con nection: 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a 54 72 61 Keep-Al ive..Tra 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 nsfer-En coding: 63 68 75 6e 6b 65 64 0d 0a 43 6f 6e 74 65 6e 74 chunked. .Content 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c -Type: t ext/html 3b 20 63 68 61 72 73 65 74 3d 75 74 66 2d 38 0d ; charse t=3Dutf-8. 0a 0d 0a 34 20 20 0d 0a c3 a9 c3 a9 0d 0a ...4 .. ...... 30 0d 0a 0d 0a 0.... ^^ ^^ ^^ ^^ When browsing to BackupPC however, I'm getting this: 36 39 20 72 e9 70 65 72 74 6f 69 72 65 73 20 72 69 r.per toires r 6 9 sp r =E9 p e r t o i r e s sp r ^^ I guess that there is some module used by BackupPC that changes the locale or binmode(STDOUT)... I'll try to see if I can do some other tests... GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Guillaume F. <gf...@lo...> - 2006-07-28 02:20:34
Attachments:
PGP.sig
|
Le 06-07-27, =E0 14:31, Guillaume Filion a =E9crit : > I'll try to see if I can do some other tests... I think I might be on to something! Disabling mod_perl on sylvester solves the problem and enabling it=20 again recreates it! A search for "mod_perl utf8" on google shows some problems between=20 these two. However, enabling mod_perl doesn't seem to create the problem on my=20 other server (ali), so while mod_perl definitly looks like a cause of=20 the problem, there might be something else that's contributing to it. As a reference for me (and other debian users): sudo /usr/sbin/apache-modconf apache disable mod_perl sudo /etc/init.d/apache restart [The problem disappear] sudo /usr/sbin/apache-modconf apache enable mod_perl sudo /etc/init.d/apache restart [The problem occurs] Good night, GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-07-31 05:19:50
|
Guillaume Filion writes: > Le 06-07-27, =E0 14:31, Guillaume Filion a =E9crit : > > I'll try to see if I can do some other tests... >=20 > I think I might be on to something! >=20 > Disabling mod_perl on sylvester solves the problem and enabling it=20 > again recreates it! >=20 > A search for "mod_perl utf8" on google shows some problems between=20 > these two. >=20 > However, enabling mod_perl doesn't seem to create the problem on my=20 > other server (ali), so while mod_perl definitly looks like a cause of=20 > the problem, there might be something else that's contributing to it. >=20 > As a reference for me (and other debian users): > sudo /usr/sbin/apache-modconf apache disable mod_perl > sudo /etc/init.d/apache restart > [The problem disappear] > sudo /usr/sbin/apache-modconf apache enable mod_perl > sudo /etc/init.d/apache restart > [The problem occurs] I'm guessing the problem relates to perl taint mode. Is perl taint turned on in your mod_perl config? Try turning it off. I don't know why taint mode should affect the charset conversion - it might relate to the eval() used to interpolate the variables when we are using utf8. Craig |
From: Guillaume F. <gf...@lo...> - 2006-08-01 12:53:05
Attachments:
signature.asc
|
Craig Barratt a =E9crit : > I'm guessing the problem relates to perl taint mode. > Is perl taint turned on in your mod_perl config? > Try turning it off. It doesn't work. The problem still occurs when I set PerlTaintCheck Off in httpd.conf... BTW, the versions I'm using are: Apache/1.3.34 (Debian) mod_perl/1.29 Strange, strange... --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Craig B. <cba...@us...> - 2006-08-02 07:06:10
|
Guillaume Filion writes: > Craig Barratt a =E9crit : > > I'm guessing the problem relates to perl taint mode. > > Is perl taint turned on in your mod_perl config? > > Try turning it off. >=20 > It doesn't work. The problem still occurs when I set PerlTaintCheck Off= > in httpd.conf... In my case (not mod_perl) if I add "-T" to the first line of BackupPC_Admin then the output strings are wrong. The browser title bar is correct, but most of the text is not. I still don't know why. I tried to create a small test program but so far it behaves correctly. Craig |
From: Guillaume F. <gf...@lo...> - 2006-08-04 12:49:59
Attachments:
signature.asc
|
Craig Barratt a =E9crit : > Guillaume Filion writes: > In my case (not mod_perl) if I add "-T" to the first line of > BackupPC_Admin then the output strings are wrong. The browser > title bar is correct, but most of the text is not. On my side, putting -T doesn't change anything: Accents work without mod_perl and don't with mod_perl. At least, disabling mod_perl is an easy workaround. GFK's --=20 Guillaume Filion, ing. jr Logidac Tech., Beaumont, Qu=E9bec, Canada - http://logidac.com/ PGP Key and more: http://guillaume.filion.org/ |
From: Klaus W. <Kla...@gm...> - 2006-08-11 19:32:40
|
Hello, Sorry to warm up this old thread, but I just found out something confusing = in=20 the documentation and my experiences in real life. Under=20 BackupPC.html#step_9__cgi_interface you can find this: To tell Apache to use mod_perl to execute BackupPC_Admin, add this to Apach= e's=20 1.x httpd.conf file: <IfModule mod_perl.c> PerlModule Apache::Registry PerlTaintCheck On <Location /cgi-bin/BackupPC/BackupPC_Admin>=20 SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On </Location> </IfModule> When I use this the browser has problem with the encoding of the german=20 umlaute (=E4, =FC, =F6). When I remove the whole Location thing everything = is=20 displayed correctly. In both cases Firefox expects utf8, just with the=20 <location> in the apache configuration it seems to be broken, without the=20 <location> utf8 seems to be valid. Is this a problem in my Apache setup or = do=20 we need to update the documentation somehow? > > Seems there is > > no line like "<meta http-equiv=3D"Content-Type" content=3D"text/html; > > charset=3DUTF-8"/>" in the <head> tag of the html files. > > That's a good hypothesis, but BackupPC sets the charset in the HTTP > headers: lib/BackupPC/CGI$ fgrep charset * > Lib.pm: print $Cgi->header(-charset =3D> "utf-8"); > > However, I was able to reproduce the problem I was getting earlier. > > I reinstalled backuppc from the latest cvs on my two servers -- both > running debian testing with perl 5.8.8. > > One of them (ali) is sending utf8 encoded web pages that render > correctly, it has LANG set to "C". > > The other one (sylvester) is sending web pages encoded in iso-latin-1 > but with a utf8 charset HTTP header. The pages don't render correctly > unless I change the encoding in Firefox to iso-latin-1. When I browse > the backups, the filenames display correctly. It has LANG set > to "fr-CA" and my locale is set to "fr_CA ISO-8859-1". > > I tried setting my locale to nothing, to fr_CA.utf8, setting the env > variable LANG=3DC, putting "no utf8;" in the lang files, but I can't get > it to work... So after all this, I'm still confused, but not for the > same reasons as before... :-( |