[feature request] Default transfer mode per app settings..

[bengur]

.. would really be great:

The default auto mode isn't 100% reliable.. from time to time it screws up the transfered data.
Binary is - for me - the only safe and viable mode, alas i need to remember to set it for every new connection/bookmark..

So plz, plz..!

regards

[JD]

Really?? I'm surprised at that, but you should know, you have 100% control over how every type of file is transferred in the Suffix Mapping table - see the Transfers menu

Please locate the suffix for type of file you're experiencing this issue with and correct the setting. Then let me know what you fixed so I can fix it here!

Alternatively you can change/remove all the entries so you essentially end up forcing Binary mode.

A default setting might be useful though. I'll see what I can do.

[bengur]

wow.. what a blitz-response time.. cudos!

Ok.. suffix mapping.. using YF for years, never stumbled there.. 8-}
So does that mean "auto" transfer mode is based on those settings, and binary overrides those?
If so, i'd actually still vote for a simple default transfer mode select in the app settings.. so one could choose
a preferred (override) mode without the need to either

* go through all the mappings and check them (tedious, tons of 'em), or
* generally nuke all of them as u suggested, or
* remember to set the mode for each connection/bookmark

Regarding what exactly happens in those rare corrupt data cases: i actually have no clue.. my best guess would be
something along BOM, mixed encoding, mixed linefeeds or such, with linefeeds being the top contender, since one
"messed up data" effect i (and other devs around me) noticed were voodoo empty lines after each line of code.
Alas i also experienced other types of corruption where the whole (php) framework would be non-functional with
garbled output .. which can't be caused just by added newlines imho..

Anyway, never actually dug into it and stuck to binary.. never any probs there.

thx & regards..

[JD]

I very highly doubt that the mapping table is wrong. It's been used successfully without any issues for several years.

What I think has happened is this : you might get double line feeds in the scenario that you're using a shared server where users upload using mixed line feed styles (CR vs CR/LF vs LF) in Binary mode when in fact they should be uploading in ASCII mode as the FTP protocol advises : in that mode, platform-specific line feed styles are converted to the CR/LF convention before transfer, and this means the receiving end knows to translate the CR/LFs into its platform specific line feed style. Of course uploading in Binary messes all that up.

I can still see how a default setting would be useful

[bengur]

I very highly doubt that the mapping table is wrong. It's been used successfully without any issues for several years.

I'm not blaming the mapping table.. don't know in detail what goes wrong and why, however this statement of yours:

Of course uploading in Binary messes all that up.

Is the exact opposite of my observations.. whenever something got craped, a check if transfer mode was set to binary
revealed i forgot to set it.. and probs disappeared right after setting it and re-uploading via binary.

In terms of what do my files (mostly php) look like encoding/lineending wise:

My standard setup - for years now - is ut8 with unix LF.. the editor is setup to enforce this and change it if needed.
The framework/CMS i'm mostly using has also been combed to this specs.. the only exceptions that might occur are
3rd party extension. Also i'm usually not in a mixed/co-working setup..

But this seems almost beside the point since - as mentioned above - a switch to binary consistently fixes the newline probs..
not only for me, but also for fellow coders.. like the one whose "doubled newlines" problem today could be fixed by switching
to binary.. (and actually made me post this request.. since he's not yet familiar with YF and was looking for the transfer settings
in the app's prefs..)

I'm fully aware i might be jumping to false conclusions, however the "switch to binary, and it'll be ok.." works so consistently,
that i just can't wrap my head around what is going on.. the more since your comment would indicate the exact opposite..

regards..

[JD]

Sorry, to be clear, I meant that the upload by others in Binary mode while you downloaded/uploaded in ASCII mode caused the problem : the mismatch of transfer modes.

So yes, "switch to binary, and it'll be ok.." approach will definitely fix the problem for you now

For what it's worth, I've added controls for the default settings for the next build, and the default is now also Binary so we can be sure not to hit up against this again.

[bengur]

For what it's worth, I've added controls for the default settings for the next build, and the default is now also Binary so we can be sure not to hit up against this again.

Excellent.. thx a lot!