bug#50988: 26.3; gnus-cloud gets wrong chunk byte count writing sync from windows

[Eli Zaretskii <eliz@gnu.org>]

> 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