Binary To ASCII?

[pbd22]

Hi.

I want to know the size of a file (prior to FTP) in ASCII Mode.
The reason is that I want to know how bit the file is going to
be once it reaches the FTP server and there is a size difference
between binary and ascii mode (100 or so bytes).

So, how do I get the size of the file in ASCII Mode using the
usual VB.NET API?

I Thank You.

 

[Cor Ligthert [MVP]]

pbd22,

Are you sure that the file is in ASCII mode. That is 7 bits that is probably
only on computers from pre CPM. At the moment is Unicode used, that is in
most situations 2 bytes per character.

Cor

 

[Tom Leylan]

I'll caution to not listen if anybody posts some odd explanation about
Unicode. A simple test writing "hello" in Notepad will easily prove that
there are 5 bytes in the file and that this has been the case "pre CP/M" as
well as in CP/M, CP/M-86, all versions of DOS and all versions of Windows
through XP. I'd be surprised if this isn't the case in Vista.

Now... what is the file a file of? I'd be surprised that any file
transmitted increases in size by some fixed number of bytes. I think what
you might be seeing is an artifact of the Windows O/S.

For instance, I have a text file with 468 bytes but it displays 1KB in a
Windows directory. It displays 468 bytes if you view the properties of that
file but it displays if you shell out to a command prompt and issue the DIR
command it reports 468 bytes. The file takes up 4K of disk space however
due to the drive cluster size.

Check the FileInfo class and the Length property, what does it report?

Tom

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Hi.

I want to know the size of a file (prior to FTP) in ASCII Mode.
The reason is that I want to know how bit the file is going to
be once it reaches the FTP server and there is a size difference
between binary and ascii mode (100 or so bytes).

So, how do I get the size of the file in ASCII Mode using the
usual VB.NET API?

I Thank You.

If the size changes with an ASCII mode transfer, then it's most likely
due to a conversion of line breaks.

A unix system uses \n as line break, while a windows system uses \r\n.
An ascii mode transfer should convert between the different styles of
line breaks to fit the system where the file is stored.

To find out what the size of a file will be after conversion, you have
to know what style of line break the source and target systems use to
know if there will be any conversion at all, and you have to examine the
data in the file to see how many line breaks it contains.

 

[Cor Ligthert [MVP]]

pbd22,

Just right click on the file and look at the sizes.

Probably that gives you the same amount for sending as receiving. What you
are seeing is the size the OS in combination with the used disk will give
you as information.

I was hoping to start a discussion with you about the by you used word
ASCII, that is mostly wrong used in this situation and gives often
misunderstandings. I thought that IBM was the one that has started once the
word "extended" ASCII for the single byte format, while the char was
represented by one byte.

However it seems Tom has set a mission for himself to terrorize post of
others, which makes that impossible. Lucky enough is the amount of post Tom
does so low in a year that it only influences a small part of the content.

Cor

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

You forgot to mention Unicode.

pbd22,

Just right click on the file and look at the sizes.

Probably that gives you the same amount for sending as receiving. What you
are seeing is the size the OS in combination with the used disk will give
you as information.

I was hoping to start a discussion with you about the by you used word
ASCII, that is mostly wrong used in this situation and gives often
misunderstandings. I thought that IBM was the one that has started once the
word "extended" ASCII for the single byte format, while the char was
represented by one byte.

However it seems Tom has set a mission for himself to terrorize post of
others, which makes that impossible. Lucky enough is the amount of post Tom
does so low in a year that it only influences a small part of the content.

Cor

 

[Tom Leylan]

I was hoping to start a discussion with you about the by you used word
ASCII, that is mostly wrong used in this situation and gives often
misunderstandings. I thought that IBM was the one that has started once
the word "extended" ASCII for the single byte format, while the char was
represented by one byte.

Except it was you who posted in other threads for people to stay on target
with their replies. Something about Google, people searching and the
international use of newsgroups or some such. If you wanted to discuss
Unicode surely you could have started such a thread, am I right?

If the original poster wants to read about unicode (which likely has nothing
to do with his question) I'd suggest he read articles by people who know the
subject rather than from somebody who goes around calling people terrorists,
C-Sharp addicts, etc.

http://en.wikipedia.org/wiki/Unicode
http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF

However it seems Tom has set a mission for himself to terrorize post of
others, which makes that impossible. Lucky enough is the amount of post
Tom does so low in a year that it only influences a small part of the
content.

Cor... you accused the producers of .PDF libraries of being thieves, you
tell people where to post, how to post and when to post. You challenge the
wording of most replies and now you are characterizing my reply as
"terrorizing others". Please grow up but at a minimum consider the impact
of your actions before you post in a public forum.

If you insist on playing this game we can begin by collecting all your inane
replies and listing them in a single thread. Your replies largely make no
sense, they are often wrong and they usually include an accusation that the
person hasn't considered something which you apparently have which is not
likely to be the case.

One day, try posting 20 lines of code that you haven't ripped from somebody
else's posting.

 

[Cor Ligthert [MVP]]

pdb.

In one of the trolling message from Tom is this link, it describes fine what
I want to say.

http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF

This means that it can be depending from the used code on the OS how long a
file will be.


Cor

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Of course the file is not in ASCII mode. There is no such thing, and you
should know that.

ASCII mode and binary mode refers to how the file is handled by the FTP
program.

 

[Tom Leylan]

In one of the trolling message from Tom is this link, it describes fine
what I want to say.

Cor: You have been decidedly more rude in the past year than I have ever
seen you before. You're intolerant of others and you resort to name calling
when somebody disagrees with whatever outlandish thing you post. You
quickly brand people as trolls or thieves or addicts or worse and frankly
it's getting boring.

I've included just some of the messages where you suggest another developer
has never used the IDE, claim they think the Earth is flat, mention Hitler,
bring up Christianity, call people trolls and tell others to not write about
politics as you write about politics, sociology and religion.

I am certain everybody is impressed with your ability to repost my answers
and I'm equally certain that everyone here can read. I posted a reply that
included some of the probable causes of the file size discrepancy and I
posted links so people could read facts (rather than opinions) about
Unicode. You on the other hand contributed little to the conversation
except to start calling people names (as you often do) when they disagree
with what largely turns out to be your incorrect guess.

Importantly I need to you stop denigrating me. If you want to point out
where I miscoded something or feel the need to point out any other fact
please do so but do not make me out to be an addict, a troll or any other
thing that is somehow less than you. I am not something less than Cor
Ligthert and I won't have you making things up to satisfy your childish
needs in a public forum.

Please keep your opinions about me to yourself. Thank you.



Mike,

I have the idea that you have never used the VB.Net IDE. Just looked at some
blogs that the world is flat and therefore it is in your opinion flat.
..
Now you are probably telling something uninvestigated in this newsgroup,
just looking at the language specifications..

Cor




Tom,

Hitler had a National Socialistic Party.

The word Socialistic had (almost) nothing to do with his party (slightly it
has and you can even debate about it).

This is equivalent for me with the static/shared class, which is no class,
until you have a complete nation behind you which is indoctrinated.

Maybe a simpler one for those not so well informed about politics in Europe.
Because somebody calls a dog a horse, does not make that a dog is a horse
although a dog has four legs.

Cor


Robin,

Be wise do not let you bring to use this newsgroup for a politic discussion.

Just ignore it,

Cor



Herfried,

The technologies is not the most important.

Let me take this time not a analogy with cars.

One of the first inventions from human was fire and how to make meat
consumable for humans, it seems that it was the start of their spread over
the world.

We still eat meat and still use in a way fire for that. However we do it
much more hygienic, a reason why we life much longer now.

Cor


Tom,

I did know you as a nice guy, being busy with VB.Net. It is striking now
that you act as a C# adict.

.... etc.

You probably start telling now that nobody knows what the interfaces or the
base classes are. If a VB.Net programmer or a C# programmer does not know
which classes implement by instance the IList or does not know that TextBox
inherits from Control than they should fast go learn that (here was another
text).

Cor



Raibeart,

Since I am a Christian,

With writting those word at the beginning of your message you are bringing
for me every true Christian in discredite, who has given you the right to
write that, for sure not Jezus Christus, because he died to fight against
what you wrote.

Your words are very insulting and therefore probably 100% responsible for
the killing of not responsible persons from whatever nation or religion
(with the first goal of course Americans). Please keep your terrorists
feeding words out of this newsgroup.

Before you think that I am afraid by terrorists. Yes I am, but I don't see
them as a part of a religion or whatever, they are for me from the same
order as you.

Cor



Tom,

I forgot to answer you about the contracts and things like that. Try to read
something about Deterding, one of the major founders of the Royal Dutch
Shell and contracts. (Royal Dutch Shell is a Dutch oil trading company).

Cor



Paul,

You may be an MVP, but this statement reveals a huge gap in your
knowledge of what reflection is and can be used for.

If you do this statement, than tell in about 10 words what reflection is,
your current text can be done by any child older than 10 and shows that you
have at least the knowledge of that, not more.

Cor



Brian,

In my opinion do you completely confirm what I wanted to say.

Let me try to say it in other words, delegates and reflections are in my
opinion no benefits, they can (are) sometimes be needed when the program
language does not give you more for (normal) humans better understandable
and readable options for that.

Cor



Mentochan,

I assume that VB Net is more OOP than C++ and C#. As I read these newsgroups
than VB Net programmers become at a certain moment more converming the
rules, while for C++ and C# programmers probably old C rules are for them as
well OOP.

However it is as well usable while ignoring that.
(There are 6 million programmers probably converting you know, a little bit
more than with other languages).

Cor



Hi,

AS you ask for Best Practice than you don't definitly not need a test to see
if your connection is open.

You control your program, so you know if it is open or not and can close it
therefore at the right time without any error.

Cor


Aalbino,

I would not say it your way, however I agree with you that it seems that
Microsoft is more and more busy hunting the next never to use solution, than
making the ones that have proven themselves to be needed really working for
100% correct.

Just my opinion.

Cor

 

[Cor Ligthert [MVP]]

Goran,

ASCII mode and binary mode refers to how the file is handled by the FTP
program.

I realized me after sending the post that some FTP programs use those texts,
however this thread is not the best thread to make a correction on that.

Probably you will see based on what I get back from a person who as far as I
can see intentionally only tries to cause disruption, often in the form of
posting messages that are inflammatory, insulting, incorrect, inaccurate,
absurd, or off-topic, with the intent of provoking a reaction from me.

I try to ignore those messages, although I have to admit that I do not
succeed completely in that as you see in this message.

Cor

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Probably you will see based on what I get back from a person who as far as I
can see intentionally only tries to cause disruption, often in the form of
posting messages that are inflammatory, insulting, incorrect, inaccurate,
absurd, or off-topic, with the intent of provoking a reaction from me.

What will I probably see? Although that sentence was quite long, still
you ended it in the middle.

 

[Tom Leylan]

Stop it Cor this is absurd you are the instigator and the person calling
people names.

You don't try to ignore anything or you wouldn't have replied in the way you
have after I have repeatedly asked you not to. Discuss the technology, stop
making things up about people and everybody would get along.

 

[pbd22]

Stop it Cor this is absurd you are the instigator and the person calling
people names.

You don't try to ignore anything or you wouldn't have replied in the way you
have after I have repeatedly asked you not to. Discuss the technology, stop
making things up about people and everybody would get along.

Thank you all for your responses. From what I gather from your
responses, it sounds like line breaks or something of that nature may
be causing the difference when the file lands on the FTP server? I did
what was suggested and right-clicked the file (these are video files,
by the way) prior to upload. I did two tests:

client: 4760952
ftp server: 4760439

client: 12444894
ftp server: 12444381

In both (indeed, all) cases, the amount of reported bytes *reduces*
once the file lands on the ftp server and the bytes are counted. In
both of the above cases, by around 500 bytes.

So, then, """how do i adjust for this programatically??""".

I am trying to do something like this in pseudo-code:

if the amt of bytes prior to upload = the amt of bytes after upload
then do something
else do something else.

The way things are going, this will never evaluate to true. Or, it
will evaluate to true at the wrong times. How do i replace the amount
of bytes taken out on the ftp server so the above condition makes
sense? Can somebody explain to me how to do this in VB.NET? I would
very much appreciate that.

Thanks for your help.

 

[Branco Medeiros]

Thank you all for your responses. From what I gather from your
responses, it sounds like line breaks or something of that nature may
be causing the difference when the file lands on the FTP server? I did
what was suggested and right-clicked the file (these are video files,
by the way) prior to upload. I did two tests:

client: 4760952
ftp server: 4760439

client: 12444894
ftp server: 12444381

In both (indeed, all) cases, the amount of reported bytes *reduces*
once the file lands on the ftp server and the bytes are counted. In
both of the above cases, by around 500 bytes.

So, then, """how do i adjust for this programatically??""".

<snip>

You don't. ASCII transfer mode, in FTP, is usable for plain text files
only (hardly the case of most files, nowadays, I guess). Video files
are **binary** files, and must be trasferred like so, otherwise
they'll certainly get corrupted.

HTH.

Regards,

Branco.

 

[pbd22]

<snip>

You don't. ASCII transfer mode, in FTP, is usable for plain text files
only (hardly the case of most files, nowadays, I guess). Video files
are **binary** files, and must be trasferred like so, otherwise
they'll certainly get corrupted.

HTH.

Regards,

Branco.

Thanks Branco.
I understand that the video file gets sent in binary. And, if the FTP
server is still in "binary mode" once the file gets there, then why
the byte difference? I guess I am still a little lost here. If
somebody could tell me how to correct the difference/problem (or
suggest a work-around) that would be the most useful for me. Thank you
for your hlep.

 

[Tom Leylan]

In both (indeed, all) cases, the amount of reported bytes *reduces*
once the file lands on the ftp server and the bytes are counted. In
both of the above cases, by around 500 bytes.

It isn't actually "around 500 bytes" but exactly 513. This number (512
actually) is a common block size for a disk drive so I'm going to guess the
source computer is using a different block size than the destination. The
computer (as you may know) doesn't write the individual bytes to drive but
rather allocates blocks. The file seems to fit in 1 less block on your FTP
server. It could be that the client has 1024 byte blocks and the server has
512 for instance.

In any case both should report the same number of bytes in the file but not
in the space they take up on the drive.

You might want to try testing a few more files and also copy one from the
server to the client to make sure it reports 513 bytes more in each case.

So, then, """how do i adjust for this programatically??""".

Sorry I don't have a good answer for that.

Tom

 

[pbd22]

It isn't actually "around 500 bytes" but exactly 513. This number (512
actually) is a common block size for a disk drive so I'm going to guess the
source computer is using a different block size than the destination. The
computer (as you may know) doesn't write the individual bytes to drive but
rather allocates blocks. The file seems to fit in 1 less block on your FTP
server. It could be that the client has 1024 byte blocks and the server has
512 for instance.

In any case both should report the same number of bytes in the file but not
in the space they take up on the drive.

You might want to try testing a few more files and also copy one from the
server to the client to make sure it reports 513 bytes more in each case.


Sorry I don't have a good answer for that.

Tom

Tom,

Thanks. You are exactly right. After doing some more testing, the
difference in byte amount from client to ftp server is exactly 513.
So, that is the problem, does anybody know the solution? I imagine
this happens a lot in FTP programming?
Anybody know of a way to adjust for this so I can accurately compare
byte counts on both client and server?

Thanks again.

 

[RobinS]

Tom,

Thanks. You are exactly right. After doing some more testing, the
difference in byte amount from client to ftp server is exactly 513.
So, that is the problem, does anybody know the solution? I imagine
this happens a lot in FTP programming?
Anybody know of a way to adjust for this so I can accurately compare
byte counts on both client and server?

Thanks again.

What is your intention? Are you just trying to figure out if the files are
identical and copied successfully? There used to be a way to calculate a
checksum for a file. If you could do that and compare them, hopefully they
would be equal regardless of the file size. This is just an idea; I don't
know how feasible it is.

Robin S.

 

[pbd22]

What is your intention? Are you just trying to figure out if the files are
identical and copied successfully? There used to be a way to calculate a
checksum for a file. If you could do that and compare them, hopefully they
would be equal regardless of the file size. This is just an idea; I don't
know how feasible it is.

Robin S.

Hi Robin,

Yes, that is pretty much all i am trying to do. I have written code on
the client
that reports the amount of bytes being loaded on the server "as it is
being loaded".
This provides the logic for a progress meter on the client. I need to
know when the file size prior transmission equals the amount of bytes
on the remote ftp server for the progress to be completed. I figured
that a byte-to-byte comparrison would be an obvious indicator but i
didn't anticipate this problem.

I will look into your checksum idea, thanks.