(Im in red Bravenet in green)




First query


Member [EDWARD C AYLWARD] February 13, 2005 05:19:19


Started having u/l probs. The size of the home file when uploaded is different on the host. This makes it impossible to do 'Compare Folders' in CuteFTP.

Example :-







2.57 KB


(2,629 bytes)







C:\Documents and Settings\HP_Administrator\My Documents\upload-inter01\test-word2002

Size 2.66 KB


(2,726 bytes)



A screen shot is here :-

Please advise.



First reply

Bravenet Web Services Support [Tyler - Support Technician] February 13, 2005 07:53:18

Dear Edward C Aylward,

The explanaition for this is best using round(ish) numbers, so I'll just address the last number you gave us.


Size on disk 4.00 KB (4,096 bytes)


Both of these numbers are the same value. (No, I am not crazy)

A KB, or Kilobyte, is 1024 bytes.



This is due to the fact that counting in computer terms is in binary.

Seems silly, but it does the trick for computer geeks.


Thank you.


Member [EDWARD C AYLWARD] February 13, 2005 07:52:35

NO!! SORRY TYLER!! Seems gibberish to me.


Yes, I do understand decimal & hexadecimal values.

I had a book published on programming. So have a simple idea of computing.


How do I specify a size for a file? It is a file that has a size!


The size of the file in the home folder is 2.66 KB (2,726 bytes). When it is u/l to the remote IT BECOMES 2.57 KB (2,629 bytes). When I u/l a file, I expect it to have a TRUE image at the host.


That does not seem to be happening.


Something has happened to the system over the past weeks. All was OK a few weeks ago.


Sorry mate,




Bravenet Web Services Support [Tyler - Support Technician] February 13, 2005 23:00:26

Dear Edward C Aylward,


The file retains the same properties when downloaded [2.56 KB (2,629 bytes)]. It looks like the file Manager is simply rounding up in bytes, and using k to indicate 1000 bytes instead of the proper Kb for every 1024 bytes.


Obviously this is very misleading so you have my apologies for the incorrect response earlier and for the confusing set up of the file manager.


Thank you for your patience


Member [EDWARD C AYLWARD] February 14, 2005 04:38:48

Thanks, Tyler,


Which 'file manager' do you mean; Bravenet or my FTP?


Yes, when the file is d/l from the host it does regain its lost bits!


I see that it happens only with html & txt files (ASCII transfer?), but not with video, sound & graphics files (binary transfer?).


Is the host amending the file 'headers'?


I'm not an expert in this area, but as this has just happened, can it be assumed that Bravenet have recently changed the upload protocol?


Please advise what action I need to take to get back to normal.


Thanks again,



Dear Edward C Aylward,


When I mentioned the File Manager I was referring to the file manager in your Bravenet account.


The file headers are the most likely source of the change in file size, but I can not say that with any certainty. I'll Give this to my manager when he gets in the morning to see if he can shed any light on the situation.


Thank you.


Cheers, Tyler.

Just to add, it is also happening to a/c spendlove-mbe.

Must be happening to all accounts? No-one else noticed?

I may experiment and see what happens if I u/l an html file by binary u/l.

Don't worry too much. You should see some of the 'cock-ups' I have had!



Member [EDWARD C AYLWARD] February 14, 2005 05:35:07

Cracked it, Tyler!

Must be the file headers when ASCII transfer is used.

I tried using Binary u/l with html files and AOK.

I think your ppl made a 'cock-up' recently. hehe! Let's know if they sort it.

Advice is, "When you u/l ALL files use Binary u/l - NOT Auto or ASCII."

My mates used to call me 'big head'. Not sure if they were right!

Not bad for a 71yo eh?!




Dear Edward C Aylward,


Wow. That was fast.


Well I will give this information to my manager.


I'm sure our programmers will be delighted to find that there was a problem discovered and isolated while they were in bed.


When I get an update on the situation I'll be sure to pass it your way.


Thank you!

(thank you)


Member [EDWARD C AYLWARD] February 14, 2005 06:12:20

Cheers, mate.


We had a TV prog here where a catch phrase was, "Gi'es a job!"

I should be saying that to your bosses? hehe

Have a gander at my site, and you will see that I am just a 'HA' (hursuit rear end!) bod.

Enjoy life, mate. It doesn't last for long.


================================= ==============================

Bravenet Web Services Support [Tim - Support Manager] February 14, 2005 17:25:30

Was this reply helpful?

Dear Edward C Aylward,


Hi, my name is Tim and I am the Director of Customer Support. I have forwarded this off to the system administration team for review. As soon as I hear back from them I will let you know.


Member [EDWARD C AYLWARD] February 15, 2005 02:58:55



All adds to the rich tapesrty of life!


Bravenet Web Services Support [Tim - Support Manager] February 15, 2005 11:29:46


Dear Edward C Aylward,


Okay, I heard back from the system administration team and apparently when you upload a file in ascii mode from windows, it will take any 2 byte windows new lines and convert them to unix 1 byte ones. Apparently this is the way our system has always worked. The only way to avoid this is to either:


a) always upload in binary mode

b) use a text/html editor that saves them with the proper line breaks.


I apologize for any inconvenience this has caused.


Member [EDWARD C AYLWARD] February 16, 2005 02:57:45

No probs, Tim,


Thing is, with Bravenet, I have always u/l using the Auto option that u/l html/text as ASCII, and not had probs until recently. Weird!


Never had the prob with other hosts either.


It was not just the new files that were affected. It seems that you had a new system maintenance prog went round all my 'old' html/text files and changed them - all 450 of them! Weird!


My knowledge of this area is a bit bare. Question - if it is OK to u/l html, text, et al, in Binary, why do we have ASCII u/l? ( I see the cr/lf issue)They seem to d/l OK.


Are there any potential probs?

Been an interesting experience.

Your service cannot be beaten.




Bravenet Web Services Support [Tim - Support Manager] February 17, 2005 11:06:28


Dear Edward C Aylward,


I heard back from the system administration team.


Here is what they told me. In order to preserve the meaning of these ends of lines when transferring files, the end of line characters have to

be changed. When going from UNIX to DOS, LF's have to be replaced with CR/LF pairs. Similarly, when going from DOS to UNIX, CR/LF pairs have to be changed to a single LF. That is the difference between them.

So it was devised as a way for UNIX and DOS users to share files without mangling the wrapping of the lines.


And yes the fact that you are uploading in ascii is probably a result of your own ftp client upgrade.


Some clients use binary mode for everything by default (I believe ws_ftp does this) and there is really no reason not to. Let me know if we can be

Of further assistance.



Member [EDWARD C AYLWARD] February 18, 2005 02:54:15

Hi, Tim,


I'm still a bit confused - but never mind!

Just hoping that by using binary u/l for my html/text files, that there may be a prob in the long term. I haven't noticed any -YET! Your comment re ws_ftp is comforting.

It seems that all users of CuteFTPpro will have the same prob with Bravenet.

I did email GlopeScape(CuteFTP) at the same time as I did you, but no response. Would it be appropriate for your ppl to liaise with them? It does seem to be a serious incompatibility with a popular FTP.

My deep thanks to you and your ppl for bearing with me in this prob.




Member [EDWARD C AYLWARD] February 22, 2005 04:31:38

Hi Tim,

Answer from CuteFTP below. Their first one was binned by my server!

The set up advice seems complicated. (I have had a look as advised and can't work it out)

If there is a simple answer, please advise, else AOK.

I am now u/l html in binary, and do not seem to be getting any probs.

Many thanks, again.




Dear Mr. Aylward,


What type of FTP server are you connecting to? It will make the

difference on how it presents the size of the file. Unix will show a

slightly different size because of it being a different Operating System.

When you view the page online, is there any difference with the file? In

the software, you can setup Smart Overwrite to assist you with the

comparing of the files. It is found under Tools > Global Options >

Transfer > Smart Overwrite. Please let me know if you have any questions on



Thank you,


Robert McElrea

Technical Support Representative


6000 Northwest Parkway, Suite 100

San Antonio, Texas 78249

1 (210) 308-8267

1 (210) 690-8824 Fax


Business Hours:

Monday through Friday / 8am to 6pm (CT)


Dear Edward C Aylward,

I don't really understand how their answer relates to the problem you are having. However, if you are uploading html now in binary and not having any problems I would just continue to do that. Thanks.