Your best friend for file transfer.Fetch
CSS file corruption (6 posts)
- Started 6 years ago by piccard
- Latest reply 5 years ago from Scott McGuire
I have two windows open, each going to a different Windows 2008 server, both connecting by SFTP. I drag all the files from one window to the other window. Everything appears to go correctly, but the CSS files are corrupted by the addition of bogus line-breaks. I suspect that they are not being treated as text files, or are being treated as text files, but not correctly so. When I upload the .css file from my Mac, it is handled correctly. Is this a known limitation? Can it be worked-around? How?
Scott McGuire Administrator
To explain what's going on requires some background.
Unlike FTP servers, most SFTP servers do not support automatic translation of line endings in text files when uploading.
So Fetch leaves line endings unchanged when you upload text files using SFTP - that is, the line endings remain the same as they were in the file on the Macintosh, regardless of whether that is appropriate for the server the files are uploaded to. (Because the alternative would be always picking one kind of conversion to do, and that choice would be just as wrong or worse than not doing any conversion at all for many people, given all the different kinds of servers there are.)
However, Fetch does perform line ending conversion when downloading text files from SFTP servers; the line ending it uses is specified in the Download pane of the Fetch Preferences.
When you drag a file from one Fetch window to another window to move the files between servers, what Fetch really does is download the file from one server, and then upload it back to the other server.
So my guess is the line endings for the CSS file on your Mac matches the line endings for the server you are uploading it to, and that is why things are fine when you upload a file directly from your Mac to the server.
However, I suspect the line ending setting for downloads is not the same as the one the one used on the target server, so when you drag the file from window to window, Fetch downloads the file, gives it new line endings, and then uploads it to the second server, doing no conversion, resulting in a mismatch.
There are several ways you could work around this problem.
First, change your download line endings preference (probably it's set to "Mac OS X and Unix," and I'd guess you'd need to set it to "Windows and DOS" to avoid the problem; but that's just a guess and you'd need to experiment). However, this may result in files you download to your Mac not having the line endings you want when working with them on your Mac (although most good Mac text editors should be able to understand Windows line endings just fine).
Second, you could transfer all your files as binary files. This would prevent any line ending conversion from taking place on either download or uploads. To do this, go to the Download pane of the Fetch Preferences and set the "Default download mode" to Binary, and go to the Upload pane and set the "Default upload mode" to be Binary (Raw Data). For your particular situation, probably all you need to do is change the Download mode to be Binary. Usually there's no harm in transferring text files as binary files, as long as the destinations can handle no line ending conversions taking place.
Finally, we do have a secret preference that lets you force Fetch to convert line endings to a certain style when uploading text files to an SFTP server (instead of doing no conversion, which is the default). That way, you could tell Fetch to always upload text files with Windows line endings, and that would probably solve the problem. Let us know if you'd like information on how to do that.
Sorry, I realize this seems like a very long answer for an apparently simple question, but it's actually kind of tricky given the issues invovled.
I set the defaults to binary up and down, and find that a single file transfer with the put and get tools buttons works. Dragging and dropping from one server window to the other still fails. Does drag and drop honor the defaults? In particular, I saw messages about transferring the HTML as text files.
Scott McGuire Administrator
Yes, drag and drop does honor the defaults. Just to be sure, I did some test server-to-server transfers of HTML files and they were transferred as binary when both defaults were set to binary.
If your connections were already open when you changed the default upload format and download mode, that might be the problem. Connections that are already open will continue to use the default formats that were in place when the connections were opened; they do not pick up changes to the defaults after they were opened. (You can change the formats for each particular window individually after they're opened, but they don't automatically change to reflect the defaults.)
So I would recommend trying the following:
* Close all open connections.
* Make sure your default upload format and download mode are set to binary.
* Open new connections to the two servers.
* Try moving files between them and see if you still have the problem.
Let us know if that works or not, and if not, we'll investigate further to figure out what is going on.
Works as expected now. Please consider an enhancement request that when working in (or at least when closing) the Fetch Preferences window, it display an advisory message if you have changed something that will NOT immediately affect open windows. That "sticky" behavior is NOT intuitive.
Please also consider an enhancement request that the log of transactions include the mode of the transfer -- it is displayed transiently on-screen during the transfer, but is readable only with slow connections or large files.
Scott McGuire Administrator
I'm glad to hear it's working now.
Thanks for the feedback. You've got a good point about the transfer mode not being listed in the transcript; for FTP connections, there's an indication about whether files are transferred as text or binary, but not for SFTP connections.
I will file feature requests in our database for both your suggestions.
Please let us know if we can be of any further assistance.
- Page 1