By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,574 Members | 3,021 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,574 IT Pros & Developers. It's quick & easy.

What's wrong with this FTP code?

P: n/a
Hi,

I must be missing something stupid. This works fine for text files,
but uploads about half of images ( jpg & png ) before cutting out, and
leaving a useless file on the server. It doesn't throw an exception,
though. My guess is the encoding is wrong, but I've tried UTF 8, and
use binary.

Any thoughts? This comes from the MSDN documentation:

try {
w = (FtpWebRequest)WebRequest.Create("ftp://" +
file.TargetPath);
w.Credentials = SiteConfigurationList.Current.Credentials;
w.Method = WebRequestMethods.Ftp.UploadFile;
w.UseBinary = true;

StreamReader sourceStream = new StreamReader(file.LocalPath,
true);
byte[] fileContents =
Encoding.UTF8.GetBytes(sourceStream.ReadToEnd());
sourceStream.Close();
w.ContentLength = fileContents.Length;

Stream requestStream = w.GetRequestStream();
requestStream.Write(fileContents, 0, fileContents.Length);
requestStream.Close();

FtpWebResponse response = (FtpWebResponse)w.GetResponse();
file.Status = file.TargetPath + "\n\n" + response.StatusCode +
":\t" + response.StatusDescription + "\n" + response.ExitMessage;
frm.AddFtpStatus(file);
response.Close();
} catch (Exception ex) {
if (file != null)
file.ErrorString = ex.Message;
if (frm != null)
frm.AddFtpStatus(file);
}

Jan 6 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
<Fo**********@gmail.comwrote:
I must be missing something stupid. This works fine for text files,
but uploads about half of images ( jpg & png ) before cutting out, and
leaving a useless file on the server. It doesn't throw an exception,
though. My guess is the encoding is wrong, but I've tried UTF 8, and
use binary.
You shouldn't use a StreamReader at all - you should use a Stream.

Readers are for text, and images aren't text.

Just open the file as a stream, then repeatedly read into a buffer,
write that buffer into the request stream, then read again until
reading returns no data.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 6 '07 #2

P: n/a
Just open the file as a stream, then repeatedly read into a buffer,
write that buffer into the request stream, then read again until
reading returns no data.
Thanks! This works perfectly.

Jan 6 '07 #3

P: n/a
Hi,

You could also use a BinaryReader and BinaryWriter to simplify the process
if you'd like:

BinaryWriter writer = new BinaryWriter(outputStream);
BinaryReader reader = new BinaryReader(inputStream);

writer.Write(reader.ReadBytes((int) inputStream.Length));

--
Dave Sexton
http://davesexton.com/blog

<Fo**********@gmail.comwrote in message
news:11**********************@42g2000cwt.googlegro ups.com...
>Just open the file as a stream, then repeatedly read into a buffer,
write that buffer into the request stream, then read again until
reading returns no data.

Thanks! This works perfectly.

Jan 7 '07 #4

P: n/a
Hi,

Ignore my last post. BinaryReader and BinaryWriter are for text (I didn't
read your post carefully enough. Sorry :)

--
Dave Sexton
http://davesexton.com/blog

<Fo**********@gmail.comwrote in message
news:11**********************@42g2000cwt.googlegro ups.com...
>Just open the file as a stream, then repeatedly read into a buffer,
write that buffer into the request stream, then read again until
reading returns no data.

Thanks! This works perfectly.

Jan 7 '07 #5

P: n/a
Dave Sexton <dave@jwa[remove.this]online.comwrote:
Ignore my last post. BinaryReader and BinaryWriter are for text (I didn't
read your post carefully enough. Sorry :)
Actually they're not - BinaryReader and BinaryWriter are badly named
classes, really, and they *are* reasonably suitable, but:

1) Your suggestion relies on the input stream's length being known to
start with. It will be for a file, but when there's a simple solution
which doesn't require it, it's nice to be able to use *any* stream.

2) Reading the whole file into memory only to write it again is
unnecessarily wasteful. The request stream will have to remember the
whole thing anyway, so why create an extra copy of the lot? It's better
(IMO) to read it in chunks. That way for a 100MB file you'll only take
100MB + the buffer size, instead of 200MB. (Actually there'll probably
be some "spare space" in the request stream, but that's the case either
way.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 7 '07 #6

P: n/a
Hi Jon,

You made some good points. I'll agree that it's a bit wasteful and in some
situations the somewhat less readable solution of using a Stream may be a
better approach. For large files, I completely agree.

As for the aptness of the BinaryReader and BinaryWriter, a constructor of
each takes an Encoding and the documentation states that the parameterless
constructors of each use UTF8 by default. How is it that these classes
aren't purely for text? If it's simply because it works with raw bytes then
what's the point of the encoding?

--
Dave Sexton
http://davesexton.com/blog

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Dave Sexton <dave@jwa[remove.this]online.comwrote:
>Ignore my last post. BinaryReader and BinaryWriter are for text (I
didn't
read your post carefully enough. Sorry :)

Actually they're not - BinaryReader and BinaryWriter are badly named
classes, really, and they *are* reasonably suitable, but:

1) Your suggestion relies on the input stream's length being known to
start with. It will be for a file, but when there's a simple solution
which doesn't require it, it's nice to be able to use *any* stream.

2) Reading the whole file into memory only to write it again is
unnecessarily wasteful. The request stream will have to remember the
whole thing anyway, so why create an extra copy of the lot? It's better
(IMO) to read it in chunks. That way for a 100MB file you'll only take
100MB + the buffer size, instead of 200MB. (Actually there'll probably
be some "spare space" in the request stream, but that's the case either
way.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jan 8 '07 #7

P: n/a
Dave Sexton <dave@jwa[remove.this]online.comwrote:
You made some good points. I'll agree that it's a bit wasteful and in some
situations the somewhat less readable solution of using a Stream may be a
better approach. For large files, I completely agree.
I try to use a consistent approach to stream handling throughout - it
means I only need to remember one way of doing things :)

(I'd also have a CopyStream method to do the copying using a buffer, so
it would be pretty obvious what's going on.)
As for the aptness of the BinaryReader and BinaryWriter, a constructor of
each takes an Encoding and the documentation states that the parameterless
constructors of each use UTF8 by default. How is it that these classes
aren't purely for text? If it's simply because it works with raw bytes then
what's the point of the encoding?
It's for text *and* binary data. The BinaryReader.ReadString and
BinaryWriter.Write(string) methods use the encoding, and likewise
ReadChars and BinaryWriter.Write(char[], int, int) methods, but the
methods which only deal with bytes and primitive types don't care about
encodings.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 8 '07 #8

P: n/a
Hi Jon,

That's good to know, thanks :)

--
Dave Sexton
http://davesexton.com/blog

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Dave Sexton <dave@jwa[remove.this]online.comwrote:
>You made some good points. I'll agree that it's a bit wasteful and in
some
situations the somewhat less readable solution of using a Stream may be a
better approach. For large files, I completely agree.

I try to use a consistent approach to stream handling throughout - it
means I only need to remember one way of doing things :)

(I'd also have a CopyStream method to do the copying using a buffer, so
it would be pretty obvious what's going on.)
>As for the aptness of the BinaryReader and BinaryWriter, a constructor of
each takes an Encoding and the documentation states that the
parameterless
constructors of each use UTF8 by default. How is it that these classes
aren't purely for text? If it's simply because it works with raw bytes
then
what's the point of the encoding?

It's for text *and* binary data. The BinaryReader.ReadString and
BinaryWriter.Write(string) methods use the encoding, and likewise
ReadChars and BinaryWriter.Write(char[], int, int) methods, but the
methods which only deal with bytes and primitive types don't care about
encodings.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Jan 8 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.