Re: 3.2.0: Bug with German umlauts
Am 10.06.2011 00:45, schrieb Stefan G. Weichinger: > cd Büro > > worked! Did that patch go into later releases? Lost track, sorry. Stefan
Re: 3.2.0: Bug with German umlauts
Am 24.06.2011 14:05, schrieb Stefan G. Weichinger: > Am 24.06.2011 12:41, schrieb Marc Muehlfeld: > >> Turning this on/off in amrecover works fine. But is there a way we >> can have this turned on by default in amrecover? We are here in >> germany and most time we have to handle files/directories with >> umlauts. > > As mentioned before this is just a matter of editing the default in > the patch ... I will do so and share as soon as I tested it. edit line 136 of the patch: from +gboolean translate_mode = FALSE; to +gboolean translate_mode = TRUE; Tested OK here. Stefan
Re: 3.2.0: Bug with German umlauts
Am 24.06.2011 12:41, schrieb Marc Muehlfeld: > Turning this on/off in amrecover works fine. But is there a way we can > have this turned on by default in amrecover? We are here in germany and > most time we have to handle files/directories with umlauts. As mentioned before this is just a matter of editing the default in the patch ... I will do so and share as soon as I tested it. Stefan
Re: 3.2.0: Bug with German umlauts
Am 09.06.2011 22:26, schrieb Jean-Louis Martineau: The attached patches add a 'settranslate' command in amrecover, there is one patch for trunk and one for 3.3. You must do: settranslate on to enable the new feature. Turning this on/off in amrecover works fine. But is there a way we can have this turned on by default in amrecover? We are here in germany and most time we have to handle files/directories with umlauts. Regards, Marc -- Marc Muehlfeld (IT-Leiter) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780 http://www.medizinische-genetik.de
Re: 3.2.0: Bug with German umlauts
Am 09.06.2011 22:26, schrieb Jean-Louis Martineau: > The attached patches add a 'settranslate' command in amrecover, there is > one patch for trunk and one for 3.3. > > You must do: settranslate on > to enable the new feature. > > I'm wondering if it shgould be on be default. Test no. 2: I upgraded/patched a second machine and created a test-DLE umlaute, containing some test-files and dirs Did an amdump to holdingdisk only and started amrecover on the other box. This looks good now: ls gives with settranslate off: 2011-06-10-11-11-59 "\\303\\244a\\303\\244\\303\\274/" 2011-06-10-11-11-59 "\\303\\237\\303\\244\\303\\266\\303\\274q/" with settranslate on: 2011-06-10-11-11-59 "äaäü/" 2011-06-10-11-11-59 "ßäöüq/" That's very good! add ä* works as well: amrecover> add ä* Added dir "/äaäü/" at date 2011-06-10-11-11-59 and the following extract worked as well, which is at least equally important ;-) - Jean-Louis, is there any difference now between looking at backups done with pre-patched amanda and looking at backups done with patched amanda? As far as I understand it should not, as the patch only affects amrecover, right? Additional question: should there be command line completion within amrecover? The manpage says: "The GNU readline library is used to provide command line history and editing" ... I certainly have amanda compiled with readline, I can use the history but I don't see completion of filenames (just a question/wish). -- This looks promising to me, I don't know how you want us to proceed? I assume we (special-locale-users) should test it for a while, right? And if I want settranslate on per default for my setup, I could for example edit line 827 of your patch, correct? Thanks a lot, Stefan!
Re: 3.2.0: Bug with German umlauts
Am 2011-06-09 22:26, schrieb Jean-Louis Martineau: > The attached patches add a 'settranslate' command in amrecover, there is > one patch for trunk and one for 3.3. > > You must do: settranslate on > to enable the new feature. > > I'm wondering if it shgould be on be default. dunno so far ;-) applied your patch, tried amrecover settranslate on, sure The display of the directory was different, but not correct: Got displayed for "ü" ... might be an issue of ssh+terminator etc BUT cd Büro worked! where before I had to use something like "B*ro" That's promising! Thanks so far, Stefan
Re: 3.2.0: Bug with German umlauts
On Wed, Jun 8, 2011 at 22:23, Stefan G. Weichinger wrote: [...] > > Francis tried to trace the problem with some patches already (in a > private thread) > And my patches were wrong for many reasons: 1. on the server side, index files store bytes >= 0x7f as \xxx where xxx is the octal representation for the char, and not only these; 2. the client <-> server interaction is not without influence either on the presence of escape sequence or even quotes. I haven't quite yet grabbed the mechanics of it. Jean-Louis sure knows more about that. Simply, I made straight use of GLib's functions in the matter since they escape/compress everything, but that does not suit the way Amanda works. -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5)
Re: 3.2.0: Bug with German umlauts
Am 08.06.2011 23:30, schrieb Jean-Louis Martineau: > All multi-bytes locale have the same problem. > > I'm working on a fix, it should be ready by end of the week. Thanks a lot, Jean-Louis, looking fwd to test stuff ...
Re: 3.2.0: Bug with German umlauts
All multi-bytes locale have the same problem. I'm working on a fix, it should be ready by end of the week. Jean-Louis Stefan G. Weichinger wrote: Am 06.06.2011 15:54, schrieb Jean-Louis Martineau: As all backup are run in the C locale, all non-ASCII characters are in octal representation in the index file. amrecover is run in the user locale, it should be able to display characters in user locale (The patch do it) On recovery, the application is also run in the C locale, but can it accept non-ASCII characters? some can and some can't. That's why the patch can't be committed. Also, it can be possible to have filename in a different locale, using the root locale to display them can make it harder. I would prefer to have an amrecover setting that enable the translation of an octal representation to a single bytes. There is a workaround, octal characters must be preceded by 4 backslash: amrecover> add 303275 Jean-Louis, thanks for the explanation, a bit steep for me ... What does it mean to me as a user? Will it get patched? Is it fixable? Will Amanda allow me to amrecover UTF8-named files without using wildcards? Francis tried to trace the problem with some patches already (in a private thread) I assume that not only german users face this issue, afai understand also users of other locales face these problems? Regards, Stefan
Re: 3.2.0: Bug with German umlauts
Am 06.06.2011 15:54, schrieb Jean-Louis Martineau: > As all backup are run in the C locale, all non-ASCII characters are in > octal representation in the index file. > amrecover is run in the user locale, it should be able to display > characters in user locale (The patch do it) > On recovery, the application is also run in the C locale, but can it > accept non-ASCII characters? some can and some can't. > That's why the patch can't be committed. > Also, it can be possible to have filename in a different locale, using > the root locale to display them can make it harder. > > I would prefer to have an amrecover setting that enable the translation > of an octal representation to a single bytes. > > There is a workaround, octal characters must be preceded by 4 backslash: > amrecover> add 303275 Jean-Louis, thanks for the explanation, a bit steep for me ... What does it mean to me as a user? Will it get patched? Is it fixable? Will Amanda allow me to amrecover UTF8-named files without using wildcards? Francis tried to trace the problem with some patches already (in a private thread) I assume that not only german users face this issue, afai understand also users of other locales face these problems? Regards, Stefan
Re: 3.2.0: Bug with German umlauts
Francis Galiegue wrote: On Mon, Jun 6, 2011 at 14:26, Stefan G. Weichinger wrote: Am 25.10.2010 09:59, schrieb Marc Muehlfeld: You fixed this in 2.5.1p2 (http://groups.yahoo.com/group/amanda-hackers/message/5233), but it came back in 3.1.1 and is still there in 3.2.0. Jean-Louis, could you tell us if there is a chance to get that fixed again? Unfortunately I am not able to find that old patch ... On this particular page, you have to click on the "Message info" link and then "Show original", but the patch will be mangled. Maybe I can help. What is the issue exactly? I don't have a pointer to the original thread. The patch replace an octal representation \000 by one byte (this is done in amindexd). As all backup are run in the C locale, all non-ASCII characters are in octal representation in the index file. amrecover is run in the user locale, it should be able to display characters in user locale (The patch do it) On recovery, the application is also run in the C locale, but can it accept non-ASCII characters? some can and some can't. That's why the patch can't be committed. Also, it can be possible to have filename in a different locale, using the root locale to display them can make it harder. I would prefer to have an amrecover setting that enable the translation of an octal representation to a single bytes. There is a workaround, octal characters must be preceded by 4 backslash: amrecover> add 303275 Jean-Louis
Re: 3.2.0: Bug with German umlauts
On Mon, Jun 6, 2011 at 15:55, Stefan G. Weichinger wrote: > Am 06.06.2011 15:52, schrieb Francis Galiegue: > >> Can you send amrecover debug logs (client) and amindexd debug logs >> (server) covering a good run and a failed run? > > I don't have good runs ... > OK, a failed run, on both sides, then? -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5)
Re: 3.2.0: Bug with German umlauts
Am 06.06.2011 15:52, schrieb Francis Galiegue: > Can you send amrecover debug logs (client) and amindexd debug logs > (server) covering a good run and a failed run? I don't have good runs ...
Re: 3.2.0: Bug with German umlauts
On Mon, Jun 6, 2011 at 15:43, Stefan G. Weichinger wrote: > Am 06.06.2011 15:35, schrieb Francis Galiegue: > >> Thanks! I'll have a look at it, but it looks like string quoting is >> back again to haunt us. > > I'd be happy to test things ... it would be a pleasure to have umlauts > and tab completion for german filenames again ... > > Thanks, Stefan > Can you send amrecover debug logs (client) and amindexd debug logs (server) covering a good run and a failed run? -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5)
Re: 3.2.0: Bug with German umlauts
Am 06.06.2011 15:35, schrieb Francis Galiegue: > Thanks! I'll have a look at it, but it looks like string quoting is > back again to haunt us. I'd be happy to test things ... it would be a pleasure to have umlauts and tab completion for german filenames again ... Thanks, Stefan
Re: 3.2.0: Bug with German umlauts
On Mon, Jun 6, 2011 at 15:14, Stefan G. Weichinger wrote: > Am 06.06.2011 14:43, schrieb Francis Galiegue: > >> On this particular page, you have to click on the "Message info" link >> and then "Show original", but the patch will be mangled. > > Ah, I see. I am not sure if to port it to the current code ... maybe it > should be done somewhere else now? > > And it seems as if it had gotten lost somewhere as the bug reappeared in > later releases. > Thanks! I'll have a look at it, but it looks like string quoting is back again to haunt us. -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5)
Re: 3.2.0: Bug with German umlauts
Am 06.06.2011 14:43, schrieb Francis Galiegue: > On this particular page, you have to click on the "Message info" link > and then "Show original", but the patch will be mangled. Ah, I see. I am not sure if to port it to the current code ... maybe it should be done somewhere else now? And it seems as if it had gotten lost somewhere as the bug reappeared in later releases. > Maybe I can help. What is the issue exactly? I don't have a pointer to > the original thread. The thread we are in currently -> http://marc.info/?t=12877342061&r=1&w=2 ;-) We are unable to amrecover files with umlauts in their names, at least it ain't easy. We have to use * and ? instead of those chars to get things right, which is rather uncomfortable, especially when you need that file fast ... Stefan
Re: 3.2.0: Bug with German umlauts
On Mon, Jun 6, 2011 at 14:26, Stefan G. Weichinger wrote: > Am 25.10.2010 09:59, schrieb Marc Muehlfeld: > >> You fixed this in 2.5.1p2 >> (http://groups.yahoo.com/group/amanda-hackers/message/5233), but it came >> back in 3.1.1 and is still there in 3.2.0. > > Jean-Louis, could you tell us if there is a chance to get that fixed > again? Unfortunately I am not able to find that old patch ... > On this particular page, you have to click on the "Message info" link and then "Show original", but the patch will be mangled. Maybe I can help. What is the issue exactly? I don't have a pointer to the original thread. -- Francis Galiegue, fgalie...@gmail.com "It seems obvious [...] that at least some 'business intelligence' tools invest so much intelligence on the business side that they have nothing left for generating SQL queries" (Stéphane Faroult, in "The Art of SQL", ISBN 0-596-00894-5)
Re: 3.2.0: Bug with German umlauts
Am 25.10.2010 09:59, schrieb Marc Muehlfeld: > You fixed this in 2.5.1p2 > (http://groups.yahoo.com/group/amanda-hackers/message/5233), but it came > back in 3.1.1 and is still there in 3.2.0. Jean-Louis, could you tell us if there is a chance to get that fixed again? Unfortunately I am not able to find that old patch ... Stefan
Re: 3.2.0: Bug with German umlauts
Am 01.06.2011 10:06, schrieb Stefan G. Weichinger: Am 22.11.2010 08:18, schrieb Marc Muehlfeld: German amanda users still searching for help with the umlaut issue, that came back. Marc, is it still there? As far as I see, yes. I see the same behavior with amanda-3.2.3 Yes, I can confirm that it is still (again) in 3.2.3. Regards, Marc -- Marc Muehlfeld (IT-Leiter) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780 http://www.medizinische-genetik.de
Re: 3.2.0: Bug with German umlauts
Am 22.11.2010 08:18, schrieb Marc Muehlfeld: > German amanda users still searching for help with the umlaut issue, that > came back. Marc, is it still there? As far as I see, yes. I see the same behavior with amanda-3.2.3 Stefan
Re: 3.2.0: Bug with German umlauts
German amanda users still searching for help with the umlaut issue, that came back. Regards, Marc Am 25.10.2010 09:59, schrieb Marc Muehlfeld: But the problem with the umlauts is still there: I can't recover files with german umlauts, only if I use wildcards. Also they are not shown in amrecover: amrecover> ls 2010-10-22-16-57-51 "M\\303\\266gliche Zusatzkosten f\\303\\274r QM-Projekt.odt" You fixed this in 2.5.1p2 (http://groups.yahoo.com/group/amanda-hackers/message/5233), but it came back in 3.1.1 and is still there in 3.2.0. -- Marc Muehlfeld (IT-Leiter) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780 http://www.medizinische-genetik.de
Re: 3.2.0: Bug with German umlauts
Am 23.10.2010 13:02, schrieb Jean-Louis Martineau: Try this new patch, remove previous patch befora applying this one. I applied the patch to the client and server. Now recovery is possible if both are 3.2.0 and using bsd auth. Thanks. But the problem with the umlauts is still there: I can't recover files with german umlauts, only if I use wildcards. Also they are not shown in amrecover: amrecover> ls 2010-10-22-16-57-51 "M\\303\\266gliche Zusatzkosten f\\303\\274r QM-Projekt.odt" You fixed this in 2.5.1p2 (http://groups.yahoo.com/group/amanda-hackers/message/5233), but it came back in 3.1.1 and is still there in 3.2.0. Regards, Marc -- Marc Muehlfeld (IT-Leiter) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 http://www.medizinische-genetik.de
Re: 3.2.0: Bug with German umlauts
Stupid me :-(
Try this new patch, remove previous patch befora applying this one.
Jean-Louis
Marc Muehlfeld wrote:
Hi Jean-Louis,
> It's a bug that can only be seen with the bsd auth.
> Attached patch fix it, can you try it?
thanks for the patch. I applied it to the client and server (both
3.2.0) and tried a restore a file without umlauts on the client:
...
Continue [?/Y/n]? y
amrecover: bad header
Extractor child exited with status 1
I attached all logfiles that were created for that try (2 from the
server, 1 from the client)
diff --git a/common-src/fileheader.c b/common-src/fileheader.c
index 32bce0d..5193837 100644
--- a/common-src/fileheader.c
+++ b/common-src/fileheader.c
@@ -132,7 +132,7 @@ parse_file_header(
tok = strtok_r(line1, " ", &saveptr);
if (tok == NULL) {
-g_debug("Empty amanda header: buflen=%zu lsize=%zu", buflen, lsize);
+g_debug("Empty amanda header: buflen=%zu lsize=%zu buf='%s'", buflen, lsize, buf);
strange_header(file, buffer, buflen, _(""), tok);
goto out;
}
diff --git a/recover-src/extract_list.c b/recover-src/extract_list.c
index baac507..958686a 100644
--- a/recover-src/extract_list.c
+++ b/recover-src/extract_list.c
@@ -96,6 +96,9 @@ static char *dump_device_name = NULL;
static char *errstr;
static char *amidxtaped_line = NULL;
extern char *localhost;
+static char header_buf[32768];
+static int header_size = 0;
+
/* global pid storage for interrupt handler */
pid_t extract_restore_child_pid = -1;
@@ -2106,6 +2109,7 @@ writer_intermediary(
ctl_data.bsu = NULL;
ctl_data.bytes_read= 0;
+header_size = 0;
security_stream_read(amidxtaped_streams[DATAFD].fd,
read_amidxtaped_data, &ctl_data);
@@ -2687,10 +2691,24 @@ read_amidxtaped_data(
GPtrArray *errarray;
g_option_t g_options;
data_path_t data_path_set = DATA_PATH_AMANDA;
+ int to_move;
+
+ to_move = MIN(32768-header_size, size);
+ memcpy(header_buf+header_size, buf, to_move);
+ header_size += to_move;
+ g_debug("read header %zd => %d", size, header_size);
+ if (header_size < 32768) {
+security_stream_read(amidxtaped_streams[DATAFD].fd,
+ read_amidxtaped_data, cookie);
+ return;
+ } else if (header_size > 32768) {
+ error("header_size is %d\n", header_size);
+ }
+ assert (to_move == size);
/* parse the file header */
fh_init(&ctl_data->file);
- parse_file_header(buf, &ctl_data->file, (size_t)size);
+ parse_file_header(header_buf, &ctl_data->file, (size_t)header_size);
/* call backup_support_option */
g_options.config = get_config_name();
Re: 3.2.0: Bug with German umlauts
Hi Jean-Louis, > It's a bug that can only be seen with the bsd auth. > Attached patch fix it, can you try it? thanks for the patch. I applied it to the client and server (both 3.2.0) and tried a restore a file without umlauts on the client: ... Continue [?/Y/n]? y amrecover: bad header Extractor child exited with status 1 I attached all logfiles that were created for that try (2 from the server, 1 from the client) Am 22.10.2010 18:06, schrieb Jean-Louis Martineau: > I suspect a bug in the handling of the bsd auth in amrecover. > Can you try the bsdtcp auth? > You need to setup an inetd/xinetd entry on the server and run > amrecover with '-oauth=bsdtcp' bsdtcp allows recovering files with and without umlauts (without just when using wildcards as workaround). Regards, Marc Am 22.10.2010 21:47, schrieb Jean-Louis Martineau: It's a bug that can only be seen with the bsd auth. Attached patch fix it, can you try it? Jean-Louis Jean-Louis Martineau wrote: Marc Muehlfeld wrote: /bin/tar: This does not look like a tar archive /bin/tar: Skipping to next header /bin/tar: Archive contains obsolescent base-64 headers /bin/tar: Read 7944 bytes from - It has nothing to do with umlauts. I suspect a bug in the handling of the bsd auth in amrecover. Can you try the bsdtcp auth? You need to setup an inetd/xinetd entry on the server and run amrecover with '-oauth=bsdtcp' Jean-Louis -- Marc Muehlfeld (IT-Leiter) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 http://www.medizinische-genetik.de Sat Oct 23 10:56:23 2010: amidxtaped: pid 1112 ruid 33 euid 33 version 3.2.0: start at Sat Oct 23 10:56:23 2010 Sat Oct 23 10:56:23 2010: amidxtaped: CTL << FEATURES=9efefbff01 Sat Oct 23 10:56:23 2010: amidxtaped: CTL << CONFIG=TestSet Sat Oct 23 10:56:23 2010: amidxtaped: CTL << LABEL=TestSet001:1 Sat Oct 23 10:56:23 2010: amidxtaped: CTL << FSF=1 Sat Oct 23 10:56:23 2010: amidxtaped: CTL << HEADER Sat Oct 23 10:56:23 2010: amidxtaped: CTL << DEVICE=HDD_Test_Changer Sat Oct 23 10:56:23 2010: amidxtaped: CTL << HOST=^genome.mr.lfmg.de$ Sat Oct 23 10:56:23 2010: amidxtaped: CTL << DISK=^/BACKUP$ Sat Oct 23 10:56:23 2010: amidxtaped: CTL << DATESTAMP=20101022165751 Sat Oct 23 10:56:23 2010: amidxtaped: CTL << END Sat Oct 23 10:56:23 2010: amidxtaped: pid 1112 ruid 33 euid 33 version 3.2.0: rename at Sat Oct 23 10:56:23 2010 Sat Oct 23 10:56:23 2010: amidxtaped: find_volume labeled 'TestSet001' Sat Oct 23 10:56:23 2010: amidxtaped: parse_inventory: load slot 1 with label 'TestSet001' Sat Oct 23 10:56:23 2010: amidxtaped: ignoring spurious Amanda::Recovery::Scan abort call Sat Oct 23 10:56:23 2010: amidxtaped: recovering from split dumpfile: date 20101022165751 host genome.mr.lfmg.de disk /BACKUP part 1/UNKNOWN lev 1 comp .gz program APPLICATION Sat Oct 23 10:56:23 2010: amidxtaped: ..with decompression applied Sat Oct 23 10:56:23 2010: amidxtaped: Building type FILE header of 32768-32768 bytes with name='genome.mr.lfmg.de' disk='/BACKUP' dumplevel=1 and blocksize=0 Sat Oct 23 10:56:25 2010: amidxtaped: CTL << AVAIL-DATAPATH AMANDA Sat Oct 23 10:56:25 2010: amidxtaped: CTL >> USE-DATAPATH AMANDA Sat Oct 23 10:56:25 2010: amidxtaped: CTL << DATAPATH-OK Sat Oct 23 10:56:25 2010: amidxtaped: Starting -> -> )> Sat Oct 23 10:56:25 2010: amidxtaped: Final linkage: -(PULL_BUFFER)-> -(READFD)-> -(WRITEFD)-> Sat Oct 23 10:56:25 2010: amidxtaped: spawning: '/bin/gzip' '-dc' Sat Oct 23 10:56:25 2010: amidxtaped: started xfer; datapath=amanda Sat Oct 23 10:56:25 2010: amidxtaped: Device file:/amandadisks/TestSet/slots/drive0 error = 'EOF' Sat Oct 23 10:56:25 2010: amidxtaped: : process exited with status 0 Sat Oct 23 10:56:25 2010: amidxtaped: recovery complete Sat Oct 23 10:56:25 2010: amidxtaped: exiting with 0 Sat Oct 23 10:56:25 2010: amidxtaped: pid 1112 finish time Sat Oct 23 10:56:25 2010 Sat Oct 23 10:56:08 2010: amindexd: pid 1105 ruid 33 euid 33 version 3.2.0: start at Sat Oct 23 10:56:08 2010 Sat Oct 23 10:56:08 2010: amindexd: version 3.2.0 Sat Oct 23 10:56:08 2010: amindexd: < 220 nucleus AMANDA index server (3.2.0) ready. Sat Oct 23 10:56:08 2010: amindexd: > FEATURES 9efefbff01 Sat Oct 23 10:56:08 2010: amindexd: < 200 FEATURES 9efefbff01 Sat Oct 23 10:56:08 2010: amindexd: > DATE 2010-10-23 Sat Oct 23 10:56:08 2010: amindexd: < 200 Working date set to 2010-10-23. Sat Oct 23 10:56:08 2010: amindexd: > SCNF TestSet Sat Oct 23 10:56:08 2010: amindexd: pid 1105 ruid 33 euid 33 version 3.2.0: rename at Sat Oct 23 10:56:08 2010 Sat Oct 23 10:56:08 2010: amindexd: < 200 Config set to TestSet. Sat Oct 23 10:56:08 2010: amindexd: > HOST genome.mr.lfmg.de Sat Oct 23 10:56:08 2010: amindexd: < 200 Dump host set to genome.mr.lfmg.de. Sat Oct 23 10:56:18 2010: amindexd: > DISK /BACKUP Sat Oct 23 10:56:18 2010: amindexd: no recover
Re: 3.2.0: Bug with German umlauts
Marc,
It's a bug that can only be seen with the bsd auth.
Attached patch fix it, can you try it?
Jean-Louis
Jean-Louis Martineau wrote:
Marc Muehlfeld wrote:
/bin/tar: This does not look like a tar archive
/bin/tar: Skipping to next header
/bin/tar: Archive contains obsolescent base-64 headers
/bin/tar: Read 7944 bytes from -
It has nothing to do with umlauts.
I suspect a bug in the handling of the bsd auth in amrecover.
Can you try the bsdtcp auth?
You need to setup an inetd/xinetd entry on the server and run
amrecover with '-oauth=bsdtcp'
Jean-Louis
diff --git a/recover-src/extract_list.c b/recover-src/extract_list.c
index baac507..3f8cbae 100644
--- a/recover-src/extract_list.c
+++ b/recover-src/extract_list.c
@@ -96,6 +96,9 @@ static char *dump_device_name = NULL;
static char *errstr;
static char *amidxtaped_line = NULL;
extern char *localhost;
+static char header_buf[32768];
+static int header_size = 0;
+
/* global pid storage for interrupt handler */
pid_t extract_restore_child_pid = -1;
@@ -2106,6 +2109,7 @@ writer_intermediary(
ctl_data.bsu = NULL;
ctl_data.bytes_read= 0;
+header_size = 0;
security_stream_read(amidxtaped_streams[DATAFD].fd,
read_amidxtaped_data, &ctl_data);
@@ -2687,7 +2691,18 @@ read_amidxtaped_data(
GPtrArray *errarray;
g_option_t g_options;
data_path_t data_path_set = DATA_PATH_AMANDA;
+ int to_move;
+
+ to_move = MIN(32768-header_size, size);
+ memcpy(header_buf+header_size, buf, to_move);
+ header_size += to_move;
+ if (header_size < 32768) {
+security_stream_read(amidxtaped_streams[DATAFD].fd,
+ read_amidxtaped_data, cookie);
+ return;
+ }
+ assert (to_move == size);
/* parse the file header */
fh_init(&ctl_data->file);
parse_file_header(buf, &ctl_data->file, (size_t)size);
Re: 3.2.0: Bug with German umlauts
Marc Muehlfeld wrote: /bin/tar: This does not look like a tar archive /bin/tar: Skipping to next header /bin/tar: Archive contains obsolescent base-64 headers /bin/tar: Read 7944 bytes from - It has nothing to do with umlauts. I suspect a bug in the handling of the bsd auth in amrecover. Can you try the bsdtcp auth? You need to setup an inetd/xinetd entry on the server and run amrecover with '-oauth=bsdtcp' Jean-Louis
Re: 3.2.0: Bug with German umlauts
Can you restore file that have no umlaut? try: add * Can you post the debug files amrecover.*.debug from the client amandad.*.debug, amindexd.*.debug and amidxtaped.*.debug from the server Send them for both run, with the 2.6.1p2 and 3.2 client. Jean-Louis Marc Muehlfeld wrote: It's getting more and more strange: Restore of a file with umlaut totally fails if you try to restore over network (client and server are both 3.2.0). It's even impossible to use wildcards: # amrecover TestSet -s nucleus -t nucleus AMRECOVER Version 3.2.0. Contacting server on nucleus ... ... amrecover> ls ... 2010-10-22-09-32-21 "M\\303\\266gliche Zusatzkosten f\\303\\274r QM-Projekt.odt" amrecover> add M* Added file "/M\\303\\266gliche Zusatzkosten f\\303\\274r QM-Projekt.odt" amrecover> extract ... Extracting files using tape drive HDD_Test_Changer on host nucleus. Load tape TestSet002 now Continue [?/Y/n/s/d]? y /bin/tar: This does not look like a tar archive /bin/tar: Skipping to next header /bin/tar: Archive contains obsolescent base-64 headers /bin/tar: Read 7944 bytes from - /bin/tar: ./M\303\266gliche Zusatzkosten f\303\274r QM-Projekt.odt: Not found in archive /bin/tar: Error exit delayed from previous errors If I downgrade the client to 2.6.1p2, I can restore files when using wildcards from an 3.2.0 server. But the usage of wildcards is still necessary. Regards, Marc
Re: 3.2.0: Bug with German umlauts
It's getting more and more strange: Restore of a file with umlaut totally fails if you try to restore over network (client and server are both 3.2.0). It's even impossible to use wildcards: # amrecover TestSet -s nucleus -t nucleus AMRECOVER Version 3.2.0. Contacting server on nucleus ... ... amrecover> ls ... 2010-10-22-09-32-21 "M\\303\\266gliche Zusatzkosten f\\303\\274r QM-Projekt.odt" amrecover> add M* Added file "/M\\303\\266gliche Zusatzkosten f\\303\\274r QM-Projekt.odt" amrecover> extract ... Extracting files using tape drive HDD_Test_Changer on host nucleus. Load tape TestSet002 now Continue [?/Y/n/s/d]? y /bin/tar: This does not look like a tar archive /bin/tar: Skipping to next header /bin/tar: Archive contains obsolescent base-64 headers /bin/tar: Read 7944 bytes from - /bin/tar: ./M\303\266gliche Zusatzkosten f\303\274r QM-Projekt.odt: Not found in archive /bin/tar: Error exit delayed from previous errors If I downgrade the client to 2.6.1p2, I can restore files when using wildcards from an 3.2.0 server. But the usage of wildcards is still necessary. Regards, Marc -- Marc Muehlfeld (IT-Leiter) Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost Lochhamer Str. 29 - D-82152 Martinsried Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-78 http://www.medizinische-genetik.de
