From unknown Sat Jun 14 03:58:11 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#50988 <50988@debbugs.gnu.org> To: bug#50988 <50988@debbugs.gnu.org> Subject: Status: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows Reply-To: bug#50988 <50988@debbugs.gnu.org> Date: Sat, 14 Jun 2025 10:58:11 +0000 retitle 50988 26.3; gnus-cloud gets wrong chunk byte count writing sync fro= m windows reassign 50988 emacs submitter 50988 sb@dod.no severity 50988 normal tag 50988 moreinfo thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 03 04:34:44 2021 Received: (at submit) by debbugs.gnu.org; 3 Oct 2021 08:34:44 +0000 Received: from localhost ([127.0.0.1]:60963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWwx4-0007Qg-Ew for submit@debbugs.gnu.org; Sun, 03 Oct 2021 04:34:44 -0400 Received: from lists.gnu.org ([209.51.188.17]:52938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWwx2-0007QW-55 for submit@debbugs.gnu.org; Sun, 03 Oct 2021 04:34:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWwx1-000354-TZ for bug-gnu-emacs@gnu.org; Sun, 03 Oct 2021 04:34:27 -0400 Received: from cadalora.default.sbang.bv.iomart.io ([2001:41c9:1:424::90]:42936) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWwwz-0003O0-C0 for bug-gnu-emacs@gnu.org; Sun, 03 Oct 2021 04:34:27 -0400 Received: from mccoy (unknown [84.210.87.211]) by cadalora.default.sbang.bv.iomart.io (Postfix) with ESMTPSA id A8BFC1000E3 for ; Sun, 3 Oct 2021 09:34:07 +0100 (BST) From: sb@dod.no To: bug-gnu-emacs@gnu.org Subject: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows Date: Sun, 03 Oct 2021 10:34:06 +0200 Message-ID: <86o886jym9.fsf@dod.no> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: none client-ip=2001:41c9:1:424::90; envelope-from=sb@dod.no; helo=cadalora.default.sbang.bv.iomart.io X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This happens for me on emacs 26.3, but has happened ever since I first tried to use gnus-cloud in 2016, so I've never been able to use gnus-cloud (I've continued to use its predecessor gnus-sync, but with emacs 27, gnus-sync no longer worked). When gnus-cloud-upload-all-data is run in gnus on emacs on windows, the byte count in the sync data chunks is wrong, so that the data is broken when attemting to sync on a debian machine. The first chunk has the following header: (:type :file :file-name "~/.gnus.el" :timestamp "2021-09-19T15:04:33+0200" :length 16241) The byte count here is 16241, but it should have been 15754. This results in the contents of the score files that follows .gnus.el to be copied into .gnus.el and the .gnus.el file becomes unparsable. The difference in length corresponds to the number of lines in .gnus.el, so I'm guessing it's because the CR in CRLF line endings is stripped away. The place where the length is set, is here https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/gnus-cloud.el#n98 I've tried taking the length of the string instead of the size of the buffer, but the count for .gnus.el still came out as 16241 (so the CR stripping doesn't take place there). I've also, as an experiment, replaced insert-file-contents-literally, with insert-file-contents, and then windows gnus wrote data that gnus-cloud-download-all-data on debian gnus could read. But that's probably not a fix, since insert-file-contents-literally is used intentionally? This is with (gnus-cloud-storage-method nil) which is what I've been using for debugging because attempts to using base64 with gzip caused error messages of the type "not base64" (presumably also because the byte count was wrong?). From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 03 05:15:46 2021 Received: (at 50988) by debbugs.gnu.org; 3 Oct 2021 09:15:46 +0000 Received: from localhost ([127.0.0.1]:32792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWxb0-0000wc-Ex for submit@debbugs.gnu.org; Sun, 03 Oct 2021 05:15:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWxaz-0000rl-RE for 50988@debbugs.gnu.org; Sun, 03 Oct 2021 05:15:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43842) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWxat-0006Wr-DR; Sun, 03 Oct 2021 05:15:39 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3262 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWxad-0007e8-5a; Sun, 03 Oct 2021 05:15:38 -0400 Date: Sun, 03 Oct 2021 12:15:08 +0300 Message-Id: <83czoma2qr.fsf@gnu.org> From: Eli Zaretskii To: sb@dod.no In-Reply-To: <86o886jym9.fsf@dod.no> (sb@dod.no) Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows References: <86o886jym9.fsf@dod.no> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sb@dod.no > Date: Sun, 03 Oct 2021 10:34:06 +0200 > > When gnus-cloud-upload-all-data is run in gnus on emacs on windows, the > byte count in the sync data chunks is wrong, so that the data is broken > when attemting to sync on a debian machine. > > The first chunk has the following header: > (:type :file :file-name "~/.gnus.el" :timestamp "2021-09-19T15:04:33+0200" :length 16241) > > The byte count here is 16241, but it should have been 15754. > > This results in the contents of the score files that follows .gnus.el to > be copied into .gnus.el and the .gnus.el file becomes unparsable. > > The difference in length corresponds to the number of lines in .gnus.el, > so I'm guessing it's because the CR in CRLF line endings is stripped > away. > > The place where the length is set, is here > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/gnus-cloud.el#n98 > > I've tried taking the length of the string instead of the size of the > buffer, but the count for .gnus.el still came out as 16241 (so the CR > stripping doesn't take place there). > > I've also, as an experiment, replaced insert-file-contents-literally, > with insert-file-contents, and then windows gnus wrote data that > gnus-cloud-download-all-data on debian gnus could read. Does the file read by that code have DOS-style CRLF end-of-line format? And what does that code have to do with your .gnus.el? (I don't use Gnus, so apologies for asking questions whose answers are trivial.) In general, if that function is supposed to read user-written files (as opposed to files Gnus itself writes), then it should not assume the EOL format is Unix. But I'm not sure insert-file-contents is the right solution here, because I don't know what will Gnus do with the file. Note that the function reads the file into a unibyte buffer, while insert-file-contents performs decoding, and these two don't mix well, usually. Do you understand why the byte count "should have been 15754"? If gnus-cloud synchronizes your files with a remote repository, then the files on the remote should have the same EOL format as on your original disk, so where does Emacs strip or ignore the CR characters to come up with a smaller number of bytes in the actual transfer? HTH From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 03 06:33:07 2021 Received: (at 50988) by debbugs.gnu.org; 3 Oct 2021 10:33:07 +0000 Received: from localhost ([127.0.0.1]:32925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWynr-0000aw-8J for submit@debbugs.gnu.org; Sun, 03 Oct 2021 06:33:07 -0400 Received: from cadalora.default.sbang.bv.iomart.io ([46.43.15.90]:45454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWyno-0000aR-63 for 50988@debbugs.gnu.org; Sun, 03 Oct 2021 06:33:06 -0400 Received: from mccoy (unknown [84.210.87.211]) by cadalora.default.sbang.bv.iomart.io (Postfix) with ESMTPSA id 8862F10464C; Sun, 3 Oct 2021 11:32:57 +0100 (BST) From: Steinar Bang To: Eli Zaretskii Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows References: <86o886jym9.fsf@dod.no> <83czoma2qr.fsf@gnu.org> Date: Sun, 03 Oct 2021 12:32:51 +0200 In-Reply-To: <83czoma2qr.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 03 Oct 2021 12:15:08 +0300") Message-ID: <86fstijt4c.fsf@dod.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> Eli Zaretskii : > Does the file read by that code have DOS-style CRLF end-of-line > format? Yes. > And what does that code have to do with your .gnus.el? (I don't use > Gnus, so apologies for asking questions whose answers are trivial.) The purpose of gnus-cloud is to create IMAP like functionality for NNTP groups. Ie. what's read and followed up on on one computer, is marked as read and followed up on a different computer (I use gnus on 3 different computers and sync state between them). gnus-cloud also syncs setup in the .gnus.el and the current state of the score files. The .gnus.el contents is the first chunk in the sync file. The mechanism of the sync is an IMAP folder with new syncs written as messages, with the body of the message consisting chunks that have a lisp-ish header, like this: (:type :file :file-name "~/.gnus.el" :timestamp "2021-09-19T15:04:33+0200" :length 16241) and then the contents of the chunk, until the next header An example: https://gist.github.com/steinarb/155c43fd102c1a929ea441b0703492a3 When the byte count in "length" is wrong, the contents of bytes past the end, are added to ~/.gnus.el in the computer synced to. > In general, if that function is supposed to read user-written files > (as opposed to files Gnus itself writes), then it should not assume > the EOL format is Unix. But I'm not sure insert-file-contents is the > right solution here, because I don't know what will Gnus do with the > file. Yes, I'm pretty sure insert-file-contents isn't the right fix either, but now it sort of works, as opposed to not working at all. So I'll limp along on that as a workaround until a real fix is. > Note that the function reads the file into a unibyte buffer, while > insert-file-contents performs decoding, and these two don't mix well, > usually. > Do you understand why the byte count "should have been 15754"? Yes. The .gnus.el file became unparsable on the synched to machine after sync, because of stuff that was added at the end (which sort of looked like gnus score files). So I looked into the contents of the file and used head to return the first 16241 bytes of the file following the header (:type :file :file-name "~/.gnus.el" :timestamp "2021-09-19T15:04:33+0200" :length 16241) and saw that this included the stuff that broke the parsing of .gnus.el: https://gist.github.com/steinarb/4ed3a4b716aab22f855df9af387cce78 (search for :type and you'll find the point where .gnus.el parsing breaks after sync). At this point I had concluded that the byte count was wrong, and the only thing I could think about as the cause, was CRLF vs LF. My .gnus.el has 487 lines and (- 16241 487) is 15754, so I tried using head to extract the first 15754 bytes of the chunk and ended up with the correct results: https://gist.github.com/steinarb/650839cec8b9961bb614b95be9c026b2 So the evidence is circumstantial but compelling (compelling to me, at least). > If gnus-cloud synchronizes your files with a remote repository, then > the files on the remote should have the same EOL format as on your > original disk, so where does Emacs strip or ignore the CR characters > to come up with a smaller number of bytes in the actual transfer? I'm not sure where the conversion happens and have been unable to figure it out. But I'm guessing the buffer inserted into here, has eol lf-only and that this is where/when the conversion happens: https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/gnus-cloud.el#n104 FWIW I didn't really want gnus-cloud to sync .gnus.el, since that file is handled as a config file checked into git. But excluding it is not a part of gnus-cloud config (at least not documented). From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 03 07:05:07 2021 Received: (at 50988) by debbugs.gnu.org; 3 Oct 2021 11:05:07 +0000 Received: from localhost ([127.0.0.1]:32953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWzIo-0001VW-Qx for submit@debbugs.gnu.org; Sun, 03 Oct 2021 07:05:07 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWzIm-0001Ux-GL for 50988@debbugs.gnu.org; Sun, 03 Oct 2021 07:05:05 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45418) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWzIg-0004sW-1Q; Sun, 03 Oct 2021 07:04:58 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2243 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWzIe-0000fA-NQ; Sun, 03 Oct 2021 07:04:57 -0400 Date: Sun, 03 Oct 2021 14:04:44 +0300 Message-Id: <83zgrq8j3n.fsf@gnu.org> From: Eli Zaretskii To: Steinar Bang In-Reply-To: <86fstijt4c.fsf@dod.no> (message from Steinar Bang on Sun, 03 Oct 2021 12:32:51 +0200) Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows References: <86o886jym9.fsf@dod.no> <83czoma2qr.fsf@gnu.org> <86fstijt4c.fsf@dod.no> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Steinar Bang > Cc: 50988@debbugs.gnu.org > Date: Sun, 03 Oct 2021 12:32:51 +0200 > > > If gnus-cloud synchronizes your files with a remote repository, then > > the files on the remote should have the same EOL format as on your > > original disk, so where does Emacs strip or ignore the CR characters > > to come up with a smaller number of bytes in the actual transfer? > > I'm not sure where the conversion happens and have been unable to figure > it out. > > But I'm guessing the buffer inserted into here, has eol lf-only and that > this is where/when the conversion happens: > https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/gnus/gnus-cloud.el#n104 Sounds unlikely: inserting a string into a buffer doesn't change the EOL format, or at least isn't supposed to. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 12 06:25:08 2022 Received: (at 50988) by debbugs.gnu.org; 12 Sep 2022 10:25:08 +0000 Received: from localhost ([127.0.0.1]:44172 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oXgcl-0005Al-Ta for submit@debbugs.gnu.org; Mon, 12 Sep 2022 06:25:08 -0400 Received: from quimby.gnus.org ([95.216.78.240]:50764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oXgck-00057W-2Z for 50988@debbugs.gnu.org; Mon, 12 Sep 2022 06:25:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AI3KxYYyIb9E3PR4ZLlAoREeF9lGO1Cl2nKGCCqX1nA=; b=TGJT5FikoJdSITTjmGrJ/TqQjC 34Q1CBVp6wkj2TDbJ7Bt2lpxgoC8BOSi2cMaFt9sQtGpMx3KVYvJP6wSRVBRSCx92hSKBsv6FMAOh cvEJ7asjs3sdtZNY1finRkO5HGPVFozveBTZK+5g8SyEPtZRCVdK1jko8hO3z2czQNuY=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXgca-0005Bt-HR; Mon, 12 Sep 2022 12:24:58 +0200 From: Lars Ingebrigtsen To: sb@dod.no Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows In-Reply-To: <86o886jym9.fsf@dod.no> (sb@dod.no's message of "Sun, 03 Oct 2021 10:34:06 +0200") References: <86o886jym9.fsf@dod.no> X-Now-Playing: Django Django's _Django Django Meets The Professor_: "Waveforms" Date: Mon, 12 Sep 2022 12:24:55 +0200 Message-ID: <87wna8ao08.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: sb@dod.no writes: > The first chunk has the following header: > (:type :file :file-name "~/.gnus.el" :timestamp > "2021-09-19T15:04:33+0200" :length 16241) > > The byte count here is 16241, but it should have been 1575 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) sb@dod.no writes: > The first chunk has the following header: > (:type :file :file-name "~/.gnus.el" :timestamp > "2021-09-19T15:04:33+0200" :length 16241) > > The byte count here is 16241, but it should have been 15754. I'm not able to reproduce this exactly, but I think I've identified a possible problem in this area now. Do you still see these issues on the current "master" branch? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 12 06:25:11 2022 Received: (at control) by debbugs.gnu.org; 12 Sep 2022 10:25:11 +0000 Received: from localhost ([127.0.0.1]:44175 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oXgcp-0005Cr-5U for submit@debbugs.gnu.org; Mon, 12 Sep 2022 06:25:11 -0400 Received: from quimby.gnus.org ([95.216.78.240]:50780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oXgcm-00058i-JZ for control@debbugs.gnu.org; Mon, 12 Sep 2022 06:25:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=O22Gk1704RTzMtua0tTFEKshNr04ncj63jBx1zTgvaM=; b=OM9yxp5CPn1z16wrXegJUK2/GQ sR8ykLBnrwtHTwOdV59YHByD87O5J1EazJdp0fAGuGkwWy1qFwZYST/YPs2pOOHg2OW3lsgUEOhLH 5nXWtuwZcXCbkfYtRgbbgH+86o1aEOAm4fQQXS3q/Dm+kQMbyqXafzEri1i6kM23/Gys=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXgce-0005By-Me for control@debbugs.gnu.org; Mon, 12 Sep 2022 12:25:02 +0200 Date: Mon, 12 Sep 2022 12:25:00 +0200 Message-Id: <87v8psao03.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #50988 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 50988 + moreinfo quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 50988 + moreinfo quit From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 13 13:29:12 2022 Received: (at 50988) by debbugs.gnu.org; 13 Sep 2022 17:29:12 +0000 Received: from localhost ([127.0.0.1]:52847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oY9ii-0005Wa-CV for submit@debbugs.gnu.org; Tue, 13 Sep 2022 13:29:12 -0400 Received: from cadalora.bang.priv.no ([46.43.15.90]:53154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oY9if-0005WJ-MW for 50988@debbugs.gnu.org; Tue, 13 Sep 2022 13:29:11 -0400 Received: from marquez (unknown [84.210.87.211]) by cadalora.bang.priv.no (Postfix) with ESMTPSA id 65CC01028D6; Tue, 13 Sep 2022 18:29:01 +0100 (BST) From: Steinar Bang To: Lars Ingebrigtsen Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows References: <86o886jym9.fsf@dod.no> <87wna8ao08.fsf@gnus.org> Date: Tue, 13 Sep 2022 19:28:58 +0200 In-Reply-To: <87wna8ao08.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 12 Sep 2022 12:24:55 +0200") Message-ID: <87zgf3ji91.fsf@dod.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> Lars Ingebrigtsen : > sb@dod.no writes: >> The first chunk has the following header: >> (:type :file :file-name "~/.gnus.el" :timestamp >> "2021-09-19T15:04:33+0200" :length 16241) >> >> The byte count here is 16241, but it should have been 15754. > I'm not able to reproduce this exactly, but I think I've identified a > possible problem in this area now. Do you still see these issues on > the current "master" branch? No, sorry! I removed gnus-cloud sync of .gnus.el and .authinfo.gpg on "Wed Oct 6 20:50:09 2021 +0200" modified .emacs @@ -783,6 +783,7 @@ to be something different.") '(gnus-cloud-interactive nil) '(gnus-cloud-method "nnimap:privat") '(gnus-cloud-storage-method nil) + '(gnus-cloud-synced-files '((:directory "~/News" :match ".*.SCORE\\'"))) '(gnus-picon-style 'right) '(gnus-treat-fill-long-lines nil) '(gnus-treat-newsgroups-picon nil) (also, I'm now using a debian GNU/linux laptop, so I don't see any CRLF/LF related issues (which I still think this was, even if Eli doesn't). I.e. not easy to reproduce) From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 08:34:33 2022 Received: (at 50988) by debbugs.gnu.org; 14 Sep 2022 12:34:33 +0000 Received: from localhost ([127.0.0.1]:54062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYRb7-00006Z-AV for submit@debbugs.gnu.org; Wed, 14 Sep 2022 08:34:33 -0400 Received: from quimby.gnus.org ([95.216.78.240]:48346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYRb5-00006I-9D for 50988@debbugs.gnu.org; Wed, 14 Sep 2022 08:34:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=sf4rD8R+iw7uy6nLaOmPM5EPIhdEqld+xQ3JmHutZ0w=; b=IjiBfHsXzEquI7k8f0vGEt1XS0 pKouiZNwD6PKEK8zOIrDuUi5/mHw+HC4pVrpIzBwqR2NIJ7Vr3qfuN5IwOk1k+VuBwagZ+Et0lMfU tCzKs0YYamBBBSJKzIv3IbcXZqDrr+tDCCKaSBQ9skEtaKoxLBinIR+qyNqQOOFoOXI4=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYRaw-0006QU-RT; Wed, 14 Sep 2022 14:34:24 +0200 From: Lars Ingebrigtsen To: Steinar Bang Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows In-Reply-To: <87zgf3ji91.fsf@dod.no> (Steinar Bang's message of "Tue, 13 Sep 2022 19:28:58 +0200") References: <86o886jym9.fsf@dod.no> <87wna8ao08.fsf@gnus.org> <87zgf3ji91.fsf@dod.no> X-Now-Playing: Mia Doi Todd's _Ten Views of Music Life_: "Shifting Sands (Jira- Remix)" Date: Wed, 14 Sep 2022 14:34:22 +0200 Message-ID: <87tu5a9ltd.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Steinar Bang writes: > (also, I'm now using a debian GNU/linux laptop, so I don't see any > CRLF/LF related issues (which I still think this was, even if Eli > doesn't). I.e. not easy to reproduce) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Steinar Bang writes: > (also, I'm now using a debian GNU/linux laptop, so I don't see any > CRLF/LF related issues (which I still think this was, even if Eli > doesn't). I.e. not easy to reproduce) OK, then I guess there won't be any further progress in this bug report, and I'm closing it. If you do see this problem again, please respond to the debbugs address and we'll reopen. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 08:34:45 2022 Received: (at control) by debbugs.gnu.org; 14 Sep 2022 12:34:45 +0000 Received: from localhost ([127.0.0.1]:54065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYRbJ-000075-LD for submit@debbugs.gnu.org; Wed, 14 Sep 2022 08:34:45 -0400 Received: from quimby.gnus.org ([95.216.78.240]:48360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYRbH-00006o-D4 for control@debbugs.gnu.org; Wed, 14 Sep 2022 08:34:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FsLZf7j9nTX3WiamJhx3GNkXQ/kUcE85ROduh7SHzrg=; b=FtZlsVSwlA77g61CFE16SnyS57 k46vNq3AaPFVB74TbEuu9C+3xr0EgndIC9S3yzIV16THh5PkJhkkgAAN266oOyZaJu6wqb4In0l7Z W8O5zzJ+aPcx2ex0YlKrZMnPB8xgq+B1AGpWkJo+dXXJBj6w7nCss+HK8fGDMQJ+qb6Y=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYRb9-0006Qd-K3 for control@debbugs.gnu.org; Wed, 14 Sep 2022 14:34:37 +0200 Date: Wed, 14 Sep 2022 14:34:35 +0200 Message-Id: <87sfku9lt0.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #50988 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 50988 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 50988 quit From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 11:04:29 2022 Received: (at 50988) by debbugs.gnu.org; 14 Sep 2022 15:04:30 +0000 Received: from localhost ([127.0.0.1]:55761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYTwD-0000cH-It for submit@debbugs.gnu.org; Wed, 14 Sep 2022 11:04:29 -0400 Received: from cadalora.bang.priv.no ([46.43.15.90]:50040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYTwB-0000c2-LN for 50988@debbugs.gnu.org; Wed, 14 Sep 2022 11:04:28 -0400 Received: from marquez (unknown [84.210.87.211]) by cadalora.bang.priv.no (Postfix) with ESMTPSA id 4B8621056BF; Wed, 14 Sep 2022 16:04:20 +0100 (BST) From: Steinar Bang To: Lars Ingebrigtsen Subject: Re: bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows References: <86o886jym9.fsf@dod.no> <87wna8ao08.fsf@gnus.org> <87zgf3ji91.fsf@dod.no> <87tu5a9ltd.fsf@gnus.org> Date: Wed, 14 Sep 2022 17:04:19 +0200 In-Reply-To: <87tu5a9ltd.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 14 Sep 2022 14:34:22 +0200") Message-ID: <87illqj8uk.fsf@dod.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 50988 Cc: 50988@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>>> Lars Ingebrigtsen : > Steinar Bang writes: >> (also, I'm now using a debian GNU/linux laptop, so I don't see any >> CRLF/LF related issues (which I still think this was, even if Eli >> doesn't). (Because if I remember correctly, the diff in byte count matched the line number...) >> I.e. not easy to reproduce) > OK, then I guess there won't be any further progress in this bug report, > and I'm closing it. If you do see this problem again, please respond to > the debbugs address and we'll reopen. +1 From unknown Sat Jun 14 03:58:11 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 13 Oct 2022 11:24:15 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator