AFAIK this receiver-side responsibility to specify the text/binary status
of the file is particularly a problem with the "ftp://" protocol because
it does not use MIME file encoding (which "http://" uses). MIME allows
the sending end of the connection to communicate whether the file is text
or binary, though it uses more bandwidth for the transfer. If the server
offers you a choice in these days of high bandwidth connections, you may be
better off sticking with http/https.
Note that MIME is not magic... if the sender is improperly configured then
the client can potentially receive corrupt data. Fortunately the most
typical MIME misconfigurations cause the file to be unchanged in all cases,
leaving it to the receiver to deal with any text file newline decoding
choice/task after the file transfer is completed.
On December 6, 2018 7:03:48 AM PST, Duncan Murdoch <
murdoch.duncan at gmail.com> wrote:
On 06/12/2018 7:45 AM, Kate Stone wrote:
Hello r-help,
Could you help me determine whether this is an R bug or not?
I've been trying to read this binary file in R:
ftp://ftp.fieldtriptoolbox.org/pub/fieldtrip/tutorial/preprocessing_erp/s04.eeg
","s04.eeg")
and I get a different length file (i.e. much longer) in Windows >= 8
x64 (build 9200) than in Ubuntu. I've tested it with different R
versions in Windows and different package versions with the same
incorrect result. Other colleagues have tested it on the same
Windows/Ubuntu builds and got the correct length.
I'm not sure whether this is an R problem or something to do with my
OS specifically, or even with the file itself. Any ideas?? I've
attached a small script demonstrating the issue.
On Windows, the `mode = "wb"` argument to download.file() is important,
otherwise it is assumed to be a text file, and LF is changed to CR LF.
There may also be handling of EOF marks, I forget.
Duncan Murdoch