{"thread":{"id":"14311","subject":"'git am' breakage with MIME decoding","startedAt":"2008-07-06T17:47:31Z","lastAt":"2008-07-07T13:39:45Z","messageCount":7,"participants":["Linus Torvalds","Don Zickus","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"82380","messageId":"alpine.LFD.1.10.0807061036500.3016@woody.linux-foundation.org","threadId":"14311","inReplyTo":null,"subject":"'git am' breakage with MIME decoding","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-06T17:47:31Z","receivedAt":"2008-07-06T17:47:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, so I generally try to avoid MIME-encoded emails because my old legacy \ntools didn't handle them, but since 'git am' is supposed to be able to \nhandle them, I just tried one. And it failed.\n\nUn-encoding them in the email client and then re-doing the thing worked \nfine, so it's definitely related to the MIME-decoding somehow.\n\nI'm attaching both versions of the email so people can test it out (it \napplies to v2.6.26-rc9 of the kernel), but the behaviour in short is that \nthe plain version (ie the one where I used my MUA to \"export\" the email \nwithout MIME crud) results in the correct:\n\n\tcommit 97f8571e663c808ad2d01a396627235167291556\n\tAuthor: Philipp Zabel \n\tDate: Sun Jul 6 01:15:34 2008 +0200\n\t\n\t pxamci: fix byte aligned DMA transfers\n\t \n\t The pxa27x DMA controller defaults to 64-bit alignment. This caused\n\t the SCR reads to fail (and, depending on card type, error out) when\n\t card->raw_scr was not aligned on a 8-byte boundary.\n ...\n\nwhile the MIME-encoded version results in\n\n\tcommit 92cdd47753abc9a6f1b8d96fedcbb5ed88b5ab57\n\tAuthor: Pierre Ossman \n\tDate: Sun Jul 6 01:15:34 2008 +0200\n\t\n\t pxamci: fix byte aligned DMA transfers\n\t \n\t F\n\t The pxa27x DMA controller defaults to 64-bit alignment. This caused\n\t the SCR reads to fail (and, depending on card type, error out) when\n\t card->raw_scr was not aligned on a 8-byte boundary.\n\t ...\n\nie notice how the \"From: Philipp Zabel \" got \ncorrupted somehow. It was apparently _partially_ recognized and removed, \nbut it left the 'F' around, and probably because of the partial removal it \nthen didn't get recognized as the author, so the original email sender \n(Pierre) got credit.\n\nThis is with a git version as of five minutes ago: v1.5.6.2-220-g44701c6.\n\nAny ideas? I have not looked at it at all, since I'm not a fan of MIME, \nand didn't have anything to do with the MIME-decoding code.\n\n\t\t\tLinus\n\nFrom torvalds@linux-foundation.org Sat Jul 5 16:17:53 2008 -0700\nReturn-Path: \nReceived: from woody.linux-foundation.org (woody.linux-foundation.org [127.0.0.1])\n\tby woody.linux-foundation.org (8.14.2/8.14.2) with ESMTP id m65NHrMl003556\n\tfor ; Sat, 5 Jul 2008 16:17:53 -0700\nReceived: from imap1.linux-foundation.org [140.211.169.55]\n\tby woody.linux-foundation.org with IMAP (fetchmail-6.3.8)\n\tfor (single-drop); Sat, 05 Jul 2008 16:17:53 -0700 (PDT)\nReceived: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13])\n\tby imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id m65NGNAD010669\n\tfor ; Sat, 5 Jul 2008 16:16:23 -0700\nReceived: from smtp.drzeus.cx (server.drzeus.cx [85.8.24.28])\n\tby smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m65NFhCI026377\n\t(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)\n\tfor ; Sat, 5 Jul 2008 16:15:46 -0700\nReceived: from mjolnir.drzeus.cx (wlan248.drzeus.cx [::ffff:10.8.2.248])\n (AUTH: LOGIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA)\n by smtp.drzeus.cx with esmtp; Sun, 06 Jul 2008 01:15:39 +0200\n id 0000000000128003.000000004870009B.00003DBE\nDate: Sun, 6 Jul 2008 01:15:34 +0200\nFrom: Pierre Ossman \nTo: Linus Torvalds \nCc: LKML ,\n Philipp Zabel ,\n Stable branch \nSubject: [PATCH] pxamci: fix byte aligned DMA transfers\nMessage-ID: <20080706011534.6dc71f5a@mjolnir.drzeus.cx>\nX-Mailer: Claws Mail 3.4.0 (GTK+ 2.13.3; i386-redhat-linux-gnu)\nMime-Version: 1.0\nContent-Type: multipart/signed; protocol=\"application/pgp-signature\"; micalg=PGP-SHA1; boundary=\"=_freyr.drzeus.cx-15806-1215299739-0001-2\"\nReceived-SPF: none (domain of drzeus-list@drzeus.cx does not designate permitted sender hosts)\nX-Spam-Status: No, hits=-6.02 required=5 tests=AWL,BAYES_00,OSDL_HEADER_SUBJECT_BRACKETED,PATCH_SUBJECT_OSDL\nX-Spam-Checker-Version: SpamAssassin 3.2.4-osdl_revision__1.47__\nX-MIMEDefang-Filter: lf$Revision: 1.188 $\nX-Scanned-By: MIMEDefang 2.63 on 140.211.169.13\nX-IMAPbase: 1215365788 1\nStatus: RO\nX-Status: \nX-Keywords: \nX-UID: 1\n\nThis is a MIME-formatted message. If you see this text it means that your\nE-mail software does not support MIME-formatted messages.\n\n--=_freyr.drzeus.cx-15806-1215299739-0001-2\nContent-Type: text/plain; charset=US-ASCII\nContent-Transfer-Encoding: quoted-printable\n\nFrom: Philipp Zabel \n\nThe pxa27x DMA controller defaults to 64-bit alignment. This caused\nthe SCR reads to fail (and, depending on card type, error out) when\ncard->raw_scr was not aligned on a 8-byte boundary.\n\nFor performance reasons all scatter-gather addresses passed to\npxamci_request should be aligned on 8-byte boundaries, but if\nthis can't be guaranteed, byte aligned DMA transfers in the\nhave to be enabled in the controller to get correct behaviour.\n\nSigned-off-by: Philipp Zabel \nSigned-off-by: Pierre Ossman \n---\n drivers/mmc/host/pxamci.c | 13 +++++++++++++\n 1 files changed, 13 insertions(+), 0 deletions(-)\n\ndiff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c\nindex 65210fc..d89475d 100644\n--- a/drivers/mmc/host/pxamci.c\n+++ b/drivers/mmc/host/pxamci.c\n@@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxamci_host *host,=\n struct mmc_data *data)\n \tunsigned int nob =3D data->blocks;\n \tunsigned long long clks;\n \tunsigned int timeout;\n+\tbool dalgn =3D 0;\n \tu32 dcmd;\n \tint i;\n=20\n@@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxamci_host *host,=\n struct mmc_data *data)\n \t\thost->sg_cpu[i].dcmd =3D dcmd | length;\n \t\tif (length & 31 && !(data->flags & MMC_DATA_READ))\n \t\t\thost->sg_cpu[i].dcmd |=3D DCMD_ENDIRQEN;\n+\t\t/* Not aligned to 8-byte boundary? */\n+\t\tif (sg_dma_address(&data->sg[i]) & 0x7)\n+\t\t\tdalgn =3D 1;\n \t\tif (data->flags & MMC_DATA_READ) {\n \t\t\thost->sg_cpu[i].dsadr =3D host->res->start + MMC_RXFIFO;\n \t\t\thost->sg_cpu[i].dtadr =3D sg_dma_address(&data->sg[i]);\n@@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxamci_host *host=\n, struct mmc_data *data)\n \thost->sg_cpu[host->dma_len - 1].ddadr =3D DDADR_STOP;\n \twmb();\n=20\n+\t/*\n+\t * The PXA27x DMA controller encounters overhead when working with\n+\t * unaligned (to 8-byte boundaries) data, so switch on byte alignment\n+\t * mode only if we have unaligned data.\n+\t */\n+\tif (dalgn)\n+\t\tDALGN |=3D (1 << host->dma);\n+\telse\n+\t\tDALGN &=3D (1 << host->dma);\n \tDDADR(host->dma) =3D host->sg_dma;\n \tDCSR(host->dma) =3D DCSR_RUN;\n }\n\n\n--=20\n -- Pierre Ossman\n\n Linux kernel, MMC maintainer http://www.kernel.org\n rdesktop, core developer http://www.rdesktop.org\n\n WARNING: This correspondence is being monitored by the\n Swedish government. Make sure your server uses encryption\n for SMTP traffic and consider using PGP for end-to-end\n encryption.\n\n--=_freyr.drzeus.cx-15806-1215299739-0001-2\nContent-Type: application/pgp-signature; name=\"signature.asc\"\nContent-Transfer-Encoding: 7bit\nContent-Disposition: attachment; filename=signature.asc\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.9 (GNU/Linux)\n\niEYEARECAAYFAkhwAJsACgkQ7b8eESbyJLjDpwCgyde8Uz/u6iHD5/JwFyH6r8hA\ndvQAoMH38ZvMg355D4R0jXmUXYfJzJds\n=YuR1\n-----END PGP SIGNATURE-----\n\n--=_freyr.drzeus.cx-15806-1215299739-0001-2--\n\n\n\nFrom drzeus-list@drzeus.cx Sat Jul 5 16:17:53 2008\nDate: Sun, 6 Jul 2008 01:15:34 +0200\nFrom: Pierre Ossman \nTo: Linus Torvalds \nCc: LKML , Philipp Zabel , Stable branch \nSubject: [PATCH] pxamci: fix byte aligned DMA transfers\n\nFrom: Philipp Zabel \n\nThe pxa27x DMA controller defaults to 64-bit alignment. This caused\nthe SCR reads to fail (and, depending on card type, error out) when\ncard->raw_scr was not aligned on a 8-byte boundary.\n\nFor performance reasons all scatter-gather addresses passed to\npxamci_request should be aligned on 8-byte boundaries, but if\nthis can't be guaranteed, byte aligned DMA transfers in the\nhave to be enabled in the controller to get correct behaviour.\n\nSigned-off-by: Philipp Zabel \nSigned-off-by: Pierre Ossman \n---\n drivers/mmc/host/pxamci.c | 13 +++++++++++++\n 1 files changed, 13 insertions(+), 0 deletions(-)\n\ndiff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c\nindex 65210fc..d89475d 100644\n--- a/drivers/mmc/host/pxamci.c\n+++ b/drivers/mmc/host/pxamci.c\n@@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)\n \tunsigned int nob = data->blocks;\n \tunsigned long long clks;\n \tunsigned int timeout;\n+\tbool dalgn = 0;\n \tu32 dcmd;\n \tint i;\n \n@@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)\n \t\thost->sg_cpu[i].dcmd = dcmd | length;\n \t\tif (length & 31 && !(data->flags & MMC_DATA_READ))\n \t\t\thost->sg_cpu[i].dcmd |= DCMD_ENDIRQEN;\n+\t\t/* Not aligned to 8-byte boundary? */\n+\t\tif (sg_dma_address(&data->sg[i]) & 0x7)\n+\t\t\tdalgn = 1;\n \t\tif (data->flags & MMC_DATA_READ) {\n \t\t\thost->sg_cpu[i].dsadr = host->res->start + MMC_RXFIFO;\n \t\t\thost->sg_cpu[i].dtadr = sg_dma_address(&data->sg[i]);\n@@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxamci_host *host, struct mmc_data *data)\n \thost->sg_cpu[host->dma_len - 1].ddadr = DDADR_STOP;\n \twmb();\n \n+\t/*\n+\t * The PXA27x DMA controller encounters overhead when working with\n+\t * unaligned (to 8-byte boundaries) data, so switch on byte alignment\n+\t * mode only if we have unaligned data.\n+\t */\n+\tif (dalgn)\n+\t\tDALGN |= (1 << host->dma);\n+\telse\n+\t\tDALGN &= (1 << host->dma);\n \tDDADR(host->dma) = host->sg_dma;\n \tDCSR(host->dma) = DCSR_RUN;\n }\n\n\n-- \n -- Pierre Ossman\n\n Linux kernel, MMC maintainer http://www.kernel.org\n rdesktop, core developer http://www.rdesktop.org\n\n WARNING: This correspondence is being monitored by the\n Swedish government. Make sure your server uses encryption\n for SMTP traffic and consider using PGP for end-to-end\n encryption.\n\n\n [ Part 2, Application/PGP-SIGNATURE (Name: \"signature.asc\") 204 bytes. ]\n [ Unable to print this part. ]\n"},{"id":"82395","messageId":"1215379261-10802-1-git-send-email-dzickus@redhat.com","threadId":"14311","inReplyTo":"alpine.LFD.1.10.0807061036500.3016@woody.linux-foundation.org","subject":"[PATCH] git-mailinfo may corrupt patch headers on attached files","fromName":"Don Zickus","fromEmail":"dzickus@redhat.com","sentAt":"2008-07-06T21:21:01Z","receivedAt":"2008-07-06T21:21:01Z","isPatch":true,"sender":{"key":"dzickus@redhat.com","avatar":null},"body":"Boundary lines in emails are treated as a special case. As a result of\nprocessing the boundary line a new line will be read into the buffer.\n\nThe string length variable 'len' is evaluated before the boundary case, thus\nthere is the possibility the length of the string does not match the new\nline read in (in the boundary line case). This causes a partial output of\nthe line to the patch file.\n\nThe fix is trivial, evaluate the length of the string right before\nprocessing it.\n\nSigned-off-by: Don Zickus \n---\n\nI noticed this the other day, just never got a chance to send the fix out.\nThis might be the same problem I ran into.\n\nCheers,\nDon\n\n builtin-mailinfo.c | 5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\nindex 2894e34..cedda18 100644\n--- a/builtin-mailinfo.c\n+++ b/builtin-mailinfo.c\n@@ -795,7 +795,7 @@ static void handle_body(void)\n \tint rc = 0;\n \tstatic char newline[2000];\n \tstatic char *np = newline;\n-\tint len = strlen(line);\n+\tint len;\n \n \t/* Skip up to the first boundary */\n \tif (content_top->boundary) {\n@@ -814,6 +814,9 @@ static void handle_body(void)\n \t\t\t\treturn;\n \t\t}\n \n+\t\t/* line may have changed after handling boundary, check len */\n+\t\tlen = strlen(line);\n+\n \t\t/* Unwrap transfer encoding */\n \t\tlen = decode_transfer_encoding(line, sizeof(line), len);\n \t\tif (len < 0) {\n-- \n1.5.6.rc2.48.g13da\n"},{"id":"82397","messageId":"alpine.LFD.1.10.0807061450240.3016@woody.linux-foundation.org","threadId":"14311","inReplyTo":"1215379261-10802-1-git-send-email-dzickus@redhat.com","subject":"Re: [PATCH] git-mailinfo may corrupt patch headers on attached files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-07-06T21:52:24Z","receivedAt":"2008-07-06T21:52:24Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 6 Jul 2008, Don Zickus wrote:\n> \n> I noticed this the other day, just never got a chance to send the fix out.\n> This might be the same problem I ran into.\n\nAck. This patch does indeed seem to fix the test-case I had. Thanks,\n\n\t\t\tLinus\n"},{"id":"82398","messageId":"7vfxqmd5kv.fsf@gitster.siamese.dyndns.org","threadId":"14311","inReplyTo":"1215379261-10802-1-git-send-email-dzickus@redhat.com","subject":"Re: [PATCH] git-mailinfo may corrupt patch headers on attached files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-06T22:13:20Z","receivedAt":"2008-07-06T22:13:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus writes:\n\n> Boundary lines in emails are treated as a special case. As a result of\n> processing the boundary line a new line will be read into the buffer.\n>\n> The string length variable 'len' is evaluated before the boundary case, thus\n> there is the possibility the length of the string does not match the new\n> line read in (in the boundary line case). This causes a partial output of\n> the line to the patch file.\n>\n> The fix is trivial, evaluate the length of the string right before\n> processing it.\n\nAh, I was about to bisect this to see where it needs to be fixed and if it\nneeds to be fixed in maint (or maint-1.5.5 and earlier). Thanks for doing\nthis before I got around to it.\n"},{"id":"82406","messageId":"7vej66blmc.fsf@gitster.siamese.dyndns.org","threadId":"14311","inReplyTo":"1215379261-10802-1-git-send-email-dzickus@redhat.com","subject":"Re: [PATCH] git-mailinfo may corrupt patch headers on attached files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T00:09:47Z","receivedAt":"2008-07-07T00:09:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"> I noticed this the other day, just never got a chance to send the fix out.\n> This might be the same problem I ran into.\n>\n> Cheers,\n> Don\n>\n> builtin-mailinfo.c | 5 ++++-\n> 1 files changed, 4 insertions(+), 1 deletions(-)\n>\n> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\n> index 2894e34..cedda18 100644\n> --- a/builtin-mailinfo.c\n> +++ b/builtin-mailinfo.c\n> @@ -795,7 +795,7 @@ static void handle_body(void)\n> \tint rc = 0;\n> \tstatic char newline[2000];\n> \tstatic char *np = newline;\n> -\tint len = strlen(line);\n> +\tint len;\n> \n> \t/* Skip up to the first boundary */\n> \tif (content_top->boundary) {\n> @@ -814,6 +814,9 @@ static void handle_body(void)\n> \t\t\t\treturn;\n> \t\t}\n> \n> +\t\t/* line may have changed after handling boundary, check len */\n> +\t\tlen = strlen(line);\n> +\n> \t\t/* Unwrap transfer encoding */\n> \t\tlen = decode_transfer_encoding(line, sizeof(line), len);\n> \t\tif (len < 0) {\n\nThis does fix the \"F\\n\" issue, but seems to break t5100 test (\"respect\nNULs\"). I haven't looked into the details yet...\n"},{"id":"82415","messageId":"7v1w269sp9.fsf@gitster.siamese.dyndns.org","threadId":"14311","inReplyTo":"1215379261-10802-1-git-send-email-dzickus@redhat.com","subject":"Re: [PATCH] git-mailinfo may corrupt patch headers on attached files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T05:19:46Z","receivedAt":"2008-07-07T05:19:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Don Zickus writes:\n\n> @@ -814,6 +814,9 @@ static void handle_body(void)\n> \t\t\t\treturn;\n> \t\t}\n> \n> +\t\t/* line may have changed after handling boundary, check len */\n> +\t\tlen = strlen(line);\n> +\n> \t\t/* Unwrap transfer encoding */\n> \t\tlen = decode_transfer_encoding(line, sizeof(line), len);\n> \t\tif (len < 0) {\n\nSorry, but I have to reject this. The reason this function treats \"len\"\nin an unnatural way is that you cannot do strlen(line) if you want to\nhandle patches that touch lines with embedded NUL in them. Ideally, the\narray line[] in the global scope should be replaced with a pair of \"char\nline[] and int linelen\" (or strbuf) so that the code will always know how\nlong the line is, but the conversion done by cce8d6f (mailsplit and\nmailinfo: gracefully handle NUL characters, 2008-05-16) and 9aa2309\n(mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths,\n2008-05-25) were done in minimally invasive way, so not all codepath in\nthe program can deal with lines with embedded NULs. For that reason, the\ncode still uses fgets() and strlen() everywhere, but the two patches\nquoted above should be careful enough to allow NULs in the contents part\nof the message (structural parts such as mime boundaries cannot have NUL\nwith the code, but it should not be a problem in practice).\n\nThe point you inserted strlen() above, however, is one of the places that\nline[] has patch text and can have NUL in it, so strlen() there would\nbreak the earlier fix.\n\nHere is the minimum replacement patch, still not handling embedded NULs\nanywhere in the structural part of the message, that should work. Sane\nMUAs should quote embedded NULs in the original contents with QP or BASE64\nto protect them from handle_boundary() and other functions, and after\ndecoding, these embedded NULs will be kept by decode_transfer_encoding(),\nso I think this would work Ok in practice.\n\nI tested this with both Linus's test message and it does not break t5100.\n\n---\n\n builtin-mailinfo.c | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-mailinfo.c b/builtin-mailinfo.c\nindex 97c1ff9..fa6e8f9 100644\n--- a/builtin-mailinfo.c\n+++ b/builtin-mailinfo.c\n@@ -812,6 +812,7 @@ static void handle_body(void)\n \t\t\t\t\t np - newline);\n \t\t\tif (!handle_boundary())\n \t\t\t\treturn;\n+\t\t\tlen = strlen(line);\n \t\t}\n \n \t\t/* Unwrap transfer encoding */\n"},{"id":"82443","messageId":"20080707133945.GB23190@redhat.com","threadId":"14311","inReplyTo":"7v1w269sp9.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-mailinfo may corrupt patch headers on attached files","fromName":"Don Zickus","fromEmail":"dzickus@redhat.com","sentAt":"2008-07-07T13:39:45Z","receivedAt":"2008-07-07T13:39:45Z","isPatch":true,"sender":{"key":"dzickus@redhat.com","avatar":null},"body":"On Sun, Jul 06, 2008 at 10:19:46PM -0700, Junio C Hamano wrote:\n> The point you inserted strlen() above, however, is one of the places that\n> line[] has patch text and can have NUL in it, so strlen() there would\n> break the earlier fix.\n> \n> Here is the minimum replacement patch, still not handling embedded NULs\n> anywhere in the structural part of the message, that should work. Sane\n> MUAs should quote embedded NULs in the original contents with QP or BASE64\n> to protect them from handle_boundary() and other functions, and after\n> decoding, these embedded NULs will be kept by decode_transfer_encoding(),\n> so I think this would work Ok in practice.\n> \n> I tested this with both Linus's test message and it does not break t5100.\n\nGood thing for test cases. :-) Thanks for the explanation.\n\nACK\n\nCheers,\nDon\n"}]}