Converting byte array to pdf throws error when opening the dcoument - c#

I am developing a WCF service that downloads a pdf file from a internet portal converts it into byte array and sends it to the client. On client side i am converting this byte array to pdf by using WriteAllBytes method. But while opening the pdf document it displays "There is error while opening the documnet. The file might be damaged or corrupted"
WCF Code
//
FileInformation fileInfo = File.OpenBinaryDirect(clientContext, fileRef.ToString());
byte[] Bytes = new byte[Convert.ToInt32(fileSize)];
fileInfo.Stream.Read(Bytes, 0, Bytes.Length);
return Bytes;
Client code
byte[] recievedBytes = <call to wcf method returing byte array>;
File.WriteAllBytes(path, recievedBytes);

I strongly suspect this is the problem:
byte[] Bytes = new byte[Convert.ToInt32(fileSize)];
fileInfo.Stream.Read(Bytes, 0, Bytes.Length);
You're assuming a single call to Read will read everything. Instead, you should loop round until you have read everything. For example:
byte[] bytes = new byte[(int) fileSize];
int index = 0;
while (index < bytes.Length)
{
int bytesRead = fileInfo.Stream.Read(bytes, index, bytes.Length - index);
if (bytesRead == 0)
{
throw new IOException("Unable to read whole file");
}
index += bytesRead;
}
Alternatively:
MemoryStream output = new MemoryStream((int) fileSize];
fileInfo.Stream.CopyTo(output);
return output.ToArray();

Related

File sent over NetworkStream is received corrupted C#

My goal is to send a file over a TCP connection using NetworkStream.
I first send the length of the data I'm going to send, and then I use a filestream and a binary writter to send the data byte by byte.
While debugging the process, I found out that some '0' bytes are being put at the beggining of the file on the receiving end.
For example, the base file's content azertyuiop is received as azerty (4 spaces replacing uiop), causing files like images to be corrupted.
The code I've got so far :
(Where br is a BinaryReader and bw is a BinaryWriter)
Sender:
using (var readStream = new FileStream(fileLocation, FileMode.Open))
{
// Send the data length first
bw.Write(new FileInfo(fileLocation).Length);
bw.Flush();
var buffer = new byte[1];
while (readStream.Read(buffer, 0, 1) > 0)
{
bw.Write(buffer[0]);
bw.Flush();
}
}
Receiver:
// Get data length
var dataLength = br.ReadInt32();
using (var fs = new FileStream(newFileLocation, FileMode.Create))
{
var buffer = new byte[1];
for(int i = 0; i < dataLength; i++)
{
br.Read(buffer, 0, 1);
fs.Write(buffer, 0, 1);
}
}
What am I missing or doing wrong ?
The problem could be the following:
bw.Write(new FileInfo(fileLocation).Length);
...
var dataLength = br.ReadInt32();
The Length property is actually of type long (8 bytes). But you are reading the value as Int32 (4 bytes), leaving the other 4 bytes in the stream.
fileinfo.length is a long not an int32

Image file from Silverlight to WCF

I'm trying to upload a photo from a Silverlight client to a server, using a WCF service.
The method called by the client is void UpdatePicture(Stream image);
This method on the client side, appears as UpdatePicture(byte[] array), so I created a converter (the input stream is a FileStream from OpenFileDialog.File.OpenRead())
private byte[] StreamToByteArray(Stream stream)
{
byte[] array = new byte[stream.Length];
stream.Read(array, 0, array.Length);
return array;
}
The converter seems to work well.
On the WCF side, I have to save the stream to a file. I use this :
public void UpdatePicture(Stream image)
{
if (SelectedUser == null)
return;
if (File.Exists(image_path + SelectedUser.sAMAccountName + ".jpg"))
{
File.Delete(image_path + SelectedUser.sAMAccountName + ".jpg");
}
using (FileStream file = File.Create(image_path + SelectedUser.sAMAccountName + ".jpg"))
{
DataManagement.CopyStream(image, file);
}
}
to copy the Stream to the FileStream, I use this :
public static void CopyStream(Stream input, Stream output)
{
byte[] buffer = new byte[8 * 1024];
int len;
while ((len = input.Read(buffer, 0, buffer.Length)) > 0)
{
output.Write(buffer, 0, len);
}
}
The file is created as expected, the size is ok, but the image is not displayed by the PhotoViewer ou any other program.
Does somebody knows why ? Any help would be very appreciated :)
EDIT :
Something really strange :
I created a WCF method GetWCFBytes(byte[] array) which returns the parameter without doing anything.
If use StreamToByteArray to pass a stream to this method as a byte array, and set the result to a Image via a BitmapImage with a MemoryStream, it displays a blank image.
If I take the OpenFileDialog's stream, convert it to a byte array, create a new MemoryStream from this array, and set my BitmapImage with it : the image is ok.
Does WCF use some magic against streams and byte arrays ?
Your CopyStream method makes sure to keep reading from the input stream until it doesn't get anything more. Your StreamToByteArray method doesn't. Are you sure you're converting the entire stream on the client, rather than just the first x bytes followed by zeroes?
private byte[] StreamToByteArray(Stream stream)
{
byte[] array = new byte[stream.Length];
int index = 0, length = 0;
while ((length = stream.Read(array, index, array.Length - index)) > 0)
{
index += length;
}
return array;
}
I find the answer, and it did have nothing to do with WCF !
The problem is that I convert my OpenFileDialog result on confirm button on in my ViewModel.
I don't know why but if I do the conversion in the method which called the openfiledialog, the byte array isn't corrupted and all work fine.
Thanks.

how to buffer an input stream until it is complete

i'm implementing a wcf service that accepts image streams. however i'm currently getting an exception when i run it. as its trying to get the length of the stream before the stream is complete. so what i'd like to do is buffer the stream until its complete. however i cant find any examples of how to do this...
can anyone help?
my code so far:
public String uploadUserImage(Stream stream)
{
Stream fs = stream;
BinaryReader br = new BinaryReader(fs);
Byte[] bytes = br.ReadBytes((Int32)fs.Length);// this causes exception
File.WriteAllBytes(filepath, bytes);
}
Rather than try to fetch the length, you should read from the stream until it returns that it's "done". In .NET 4, this is really easy:
// Assuming we *really* want to read it into memory first...
MemoryStream memoryStream = new MemoryStream();
stream.CopyTo(memoryStream);
memoryStream.Position = 0;
File.WriteAllBytes(filepath, memoryStream);
In .NET 3.5 there's no CopyTo method, but you can write something similar yourself:
public static void CopyStream(Stream input, Stream output)
{
byte[] buffer = new byte[8192];
int bytesRead;
while ((bytesRead = input.Read(buffer, 0, buffer.Length)) > 0)
{
output.Write(buffer, 0, bytesRead);
}
}
However, now we've got something to copy a stream, why bother reading it all into memory first? Let's just write it straight to a file:
using (FileStream output = File.OpenWrite(filepath))
{
CopyStream(stream, output); // Or stream.CopyTo(output);
}
I'm not sure what you are returning (or not returning), but something like this might work for you:
public String uploadUserImage(Stream stream) {
const int KB = 1024;
Byte[] bytes = new Byte[KB];
StringBuilder sb = new StringBuilder();
using (BinaryReader br = new BinaryReader(stream)) {
int len;
do {
len = br.Read(bytes, 0, KB);
string readData = Encoding.UTF8.GetString(bytes);
sb.Append(readData);
} while (len == KB);
}
//File.WriteAllBytes(filepath, bytes);
return sb.ToString();
}
A string can hold up to 2 GB, I believe.
Try this :
using (StreamWriter sw = File.CreateText(filepath))
{
stream.CopyTo(sw);
sw.Close();
}
Jon Skeets answer for .Net 3.5 and below using a Buffer Read is actually done incorrectly.
The buffer isn't cleared between reads which can result in issues on any read that returns less than 8192, for example if the 2nd read, read 192 bytes, the 8000 last bytes from the first read would STILL be in the buffer which would then be returned to the stream.
My code below you supply it a Stream and it will return a IEnumerable array.
Using this you can for-each it and Write to a MemoryStream and then use .GetBuffer() to end up with a compiled merged byte[].
private IEnumerable<byte[]> ReadFullStream(Stream stream) {
while(true) {
byte[] buffer = new byte[8192];//since this is created every loop, its buffer is cleared
int bytesRead = stream.Read(buffer, 0, buffer.Length);//read up to 8192 bytes into buffer
if (bytesRead == 0) {//if we read nothing, stream is finished
break;
}
if(bytesRead < buffer.Length) {//if we read LESS than 8192 bytes, resize the buffer to essentially remove everything after what was read, otherwise you will have nullbytes/0x00bytes at the end of your buffer
Array.Resize(ref buffer, bytesRead);
}
yield return buffer;//yield return the buffer data
}//loop here until we reach a read == 0 (end of stream)
}

data loss when file is transfer from server to client using stream in c#

server side
stream.BeginWrite(clientData, 0, clientData.Length,
new AsyncCallback(CompleteWrite), stream);
client side
int tot = s.Read(clientData, 0, clientData.Length);
I have used TCPClient,TCPlistener classes
clientData is a byte array.Size of ClientData is 2682 in server side.I have used NetworkStream class to write data
but in client side received data contains only 1642 bytes.I have used stream class to read data in client side
What's wrong?
The Read method is permitted to return fewer bytes than you requested. You need to call Read repeatedly until you have received the number of bytes you want.
Use this method to read properly from a stream:
public static void ReadWholeArray (Stream stream, byte[] data)
{
int offset=0;
int remaining = data.Length;
while (remaining > 0)
{
int read = stream.Read(data, offset, remaining);
if (read <= 0)
throw new EndOfStreamException
(String.Format("End of stream reached with {0} bytes left to read", remaining));
remaining -= read;
offset += read;
}
}
You may want to Write the length of the file into the stream first (say as an int)
eg,
server side:
server.Write(clientData.Length)
server.Write(clientData);
client side:
byte[] size = new byte[4];
ReadWholeArray(stream, size);
int fileSize = BitConverter.ToInt32(size, 0);
byte[] fileBytes = new byte[fileSize];
ReadWholeArray(stream, fileBytes);
see http://www.yoda.arachsys.com/csharp/readbinary.html for more info on reading from streams.

Uncompress data file with DeflateStream

I'm having trouble reading a compressed (deflated) data file using C# .NET DeflateStream(..., CompressionMode.Decompress). The file was written earlier using DeflateStream(..., CompressionMode.Compress), and it seems to be just fine (I can even decompress it using a Java program).
However, the first Read() call on the input stream to decompress/inflate the compressed data returns a length of zero (end of file).
Here's the main driver, which is used for both compression and decompression:
public void Main(...)
{
Stream inp;
Stream outp;
bool compr;
...
inp = new FileStream(inName, FileMode.Open, FileAccess.Read);
outp = new FileStream(outName, FileMode.Create, FileAccess.Write);
if (compr)
Compress(inp, outp);
else
Decompress(inp, outp);
inp.Close();
outp.Close();
}
Here's the basic code for decompression, which is what is failing:
public long Decompress(Stream inp, Stream outp)
{
byte[] buf = new byte[BUF_SIZE];
long nBytes = 0;
// Decompress the contents of the input file
inp = new DeflateStream(inp, CompressionMode.Decompress);
for (;;)
{
int len;
// Read a data block from the input stream
len = inp.Read(buf, 0, buf.Length); //<<FAILS
if (len <= 0)
break;
// Write the data block to the decompressed output stream
outp.Write(buf, 0, len);
nBytes += len;
}
// Done
outp.Flush();
return nBytes;
}
The call marked FAILS always returns zero. Why? I know it's got to be something simple, but I'm just not seeing it.
Here's the basic code for compression, which works just fine, and is almost exactly the same as the decompression method with the names swapped:
public long Compress(Stream inp, Stream outp)
{
byte[] buf = new byte[BUF_SIZE];
long nBytes = 0;
// Compress the contents of the input file
outp = new DeflateStream(outp, CompressionMode.Compress);
for (;;)
{
int len;
// Read a data block from the input stream
len = inp.Read(buf, 0, buf.Length);
if (len <= 0)
break;
// Write the data block to the compressed output stream
outp.Write(buf, 0, len);
nBytes += len;
}
// Done
outp.Flush();
return nBytes;
}
Solved
After seeing the correct solution, the constructor statement should be changed to:
inp = new DeflateStream(inp, CompressionMode.Decompress, true);
which keeps the underlying input stream open, and the following line needs to be added following the inp.Flush() call:
inp.Close();
The Close() calls forces the deflater stream to flush its internal buffers. The true flag prevents it from closing the underlying stream, which is closed later in Main(). The same changes should also be made to the Compress() method.
In your decompress method, are reassigning inp to a new Stream (a deflate stream). You never close that Deflate stream, but you do close the underlying file stream in Main(). A similar thing is going on in the compress method.
I think that the problem is that the underlying file stream is being closed before the deflate stream's finalizers are automatically closing them.
I added 1 line of code to your Decompress and Compress methods:
inp.Close() // to the Decompressmehtod
outp.Close() // to the compress method.
a better practice would be to enclose the streams in a using clause.
Here's an alternative way to write your Decompress method (I tested, and it works)
public static long Decompress(Stream inp, Stream outp)
{
byte[] buf = new byte[BUF_SIZE];
long nBytes = 0;
// Decompress the contents of the input file
using (inp = new DeflateStream(inp, CompressionMode.Decompress))
{
int len;
while ((len = inp.Read(buf, 0, buf.Length)) > 0)
{
// Write the data block to the decompressed output stream
outp.Write(buf, 0, len);
nBytes += len;
}
}
// Done
return nBytes;
}
I had the same problem with GZipStream, Since we had the original length stored I had to re-write the code to only read the number of bytes expected in the original file.
Hopefully I'm about to learn that there was a better answer (fingers crossed).

Categories