Backblaze
Error when b2 writes non-ASCII to stdout
The command
b2 sync --noProgress --keepDays 14 /home/data/v2 b2://backup/ > /path/to/logfile
produced this error on stderr.
WARNING:b2sdk.sync.report:could not output the following line with encoding None on stdout due
to 'ascii' codec can't encode character u'\xfa' in position 40: ordinal not in range(128):
upload files/Playlist-for-Derecho-a-la-música-9-15-19.csv
I think this is not my fault as a user of the b2 command.
If b2 uses ASCII on stdout then it should take care to not send any non-ASCII characters to stdout to avoid this python error.
Better than that is to use UTF-8 for stdout, at least when it is not connected to a term.
It seems that you are using a slightly misconfigured terminal. b2sdk sync reporter outputs names of transferred files on stdout, but if stdout cannot accept (for example) utf-8 and the file names are encoded in utf-8, B2CLI cannot perform it's job, that's why the warning is generated.
I think this happens because python is unable to detect encoding (it says the encoding is "None"). Could you please try to run a simple command with --verbose and show us the output, so that we can see the encoding settings reported by it? (please remove any sensitive information)
I'm not using a terminal. I said so in the OP.
The error case is when stdout from b2 is piped to a file. And the command is not even run from a term, it is run from a cron.hourly script.
According to what I read about Python, when stdout is piped to a file, Python does not assign a codec to that file pointer. (That seems perfectly reasonable to me.) So unless you set it to something different, it's going to be "None".
In such a case I would say it is up to b2 to either set a codec or to use the "None" codec that is Python's default correctly and not send to it characters that cause an error.
Sorry, I used my personal Github account for the OP by mistake. @tom-- and @spinitron are both me.
If the CLI silently swallows non-ascii characters during output, it can report wrong things such as files ał and a being transferred will be indistinguishable.
I think we should set the output encoding to utf-8 if python cannot determine it (and sets it to None). @bwbeach, is that a good idea?
That would fix my problem since file names are encoded in UTF-8 on my systems. Binary strings would be more general since 1) that's what output pipes/files are, and 2) filenames on Linux filesystems are binary so that users can use any encoding.