10374 Blank FTP errors

[chrisjj]

Could you please tell me where in the log are these empty error messages on which the failure is being blamed?

[Aaron]

Chrisjj,

The empty lines in the log pane are the blank lines. We don't intentionally insert whitespace into our log. You can see them in your screenshots (in the green pane: any empty lines). These are also the lines that should be in the Error dialog, but since they are empty it appears the dialog is empty. You noticed there are actually 11 empty lines in there as well.

If it is blank, then it is likely the error message returned can't be intrepretted. This is possibly due to an encoding issue between the server and BC3.
We currently don't catch this behavior; we should. But we also can't troubleshoot on just a blank error message from the server.

We will be fixing the blank messages reporting in a future release by inserting a generic message, but if you want to solve the issue so the error does not happen, then you will have to help us determine the cause.

[chrisjj]

> The empty lines in the log pane are the blank lines.

Sure the "empty lines" are "blank lines". But what I'm asking about is your claim:

>~> The empty messages are from the OS X Server returning an empty
>~> string as the error message

I see no evidence at all that the server is returning an empty string (or empty line, or blank line) as an error message. As I said, what I see is the server returning an "Invalid argument" string - and BC is failing to show that in its error window.

[Aaron]

We cannot yet determine what the server is sending. They appear to be empty strings, but it may actually be an encoding error interpretting them. It is hard to say without more detail and troubleshooting.

If you have the time to try our test, please let us know. We will attempt our own tests in the office in the meantime.

[Zoë]

But what I'm asking about is your claim:

Aaron was mistaken when he said that. He's not the FTP dev, I am, and I made no such claim. If you'd answered my questions instead of fixating on that we would have had this solved much earlier.

To answer my own question: Changing the encoding would have avoided the errors but wouldn't have fixed the issue with empty error messages when you did get an error. That will be fixed in the next release.

You need to changing your encoding to UTF-8 in your FTP profile. You will not be able to upload files with extended characters until you do. Even once you do, BC may not align the files once you upload them because OS X and Windows store the extended characters differently.

[chrisjj]

> Aaron was mistaken when he said that.

Thanks for that clarification.

> the issue with empty error messages when you did get an error.
> That will be fixed in the next release.

Thanks.

In case it helps, here's an instance in which the line following the error message is /not/ blank:

http://img444.imageshack.us/img444/3138/71912264.gif

[Zoë]

In case it helps, here's an instance in which the line following the error message is /not/ blank:

In that case it's just two lines later instead of one, and that likely just means that the background thread interacted with the log's display a little differently. If you had two connections going their commands can be shown as interleaved too.

In any case, I was able to get OS X 10.3 running here and was able to reproduce the error. It is related to the character encoding used by the connection. The blank error messages should be fixed in the next release, but like I said previously, you will need to change your encoding in order to actually upload those files.

[chrisjj]

> In that case it's just two lines later instead of one, and that likely just means
> that the background thread interacted with the log's display a little differently.

It might help if those blank lines were tagged like the regular lines. Currently there's not even an indication of which direction they are going in.

[Zoë]

I guess I never described what's actually going on. Internally the "blank" lines have contents, along the lines of:

2009-07-27 22:20:36 Unable to copy Carlos[...].htm: Invalid argument

The problem is that when we try to draw that line we have to convert that from UTF-8 to UTF-16, and the conversion fails, so no text is drawn. If you save the log to a file and open it in an editor it should show the missing line. So, we can't add anything to the line to make it obvious what's going on, since that won't show up either.

[chrisjj]

> I guess I never described what's actually going on.

I guess you're right!

> If you save the log to a file and open it in an editor it should show the missing line.

It does. Useful workaround - thanks.

BTW, you might like to know Copy to Clipboard silently fails if the selection includes one of these bogus blank lines.

[chrisjj]

> and that likely just means that the background thread interacted with the log's display a little
> differently. If you had two connections going their commands can be shown as interleaved too.

FTR, Simultaneous connections was set to 1.