This project is read-only.

Creating Zip file from DB String

Sep 21, 2009 at 9:59 PM
Edited Sep 21, 2009 at 10:03 PM

I can create a zip file if I hard code the file path.

Zip.AddFile(C:\filename.pdf", "")
Zip.AddFile("C:\Test.txt", "")

This works! 

If I place the same values into a file array, it fails

filenames = fileList.ToArray()
Zip.AddFile(filenames(0), "")
Zip.AddFile(filenames(1), "")

I have my file name and path stored in a database.  I need to read the file name and path and create a zip file to be downloaded.

Yes, the values are the same in the filenames array. 

What am I doing wrong?

I have trying reading the file into a memorystream.  It works if the path is hard codes, but once I use variables the zip file is damaged.  It says the file name are too long.  I can open it, but each file name has .... at the end.  Again, if I put the hard code the file path everything is ok. 

The files are stored on a network share.  I have full permission.  Everything works ok if I hard code the path (type it in).  If I use variables, the zip file is damaged and can not view it.  It has to be something with how my variables are defined.  I have tried Lists, arrays, reading from a database and any other method I could find or think of. 

Sep 22, 2009 at 7:49 AM

I suggest you employ:

  • a using clause.  Follow the examples in the doc.
  • a try...catch clause.  If the zip file is damaged there is likely an exception occurring. Maybe you're missing it.
  • a call Response.Close(). 

You may be including these things but you don't show them.

I don't know what this means:  "It says the file name are too long.  I can open it, but each file name has .... at the end."   How do you view the value of the filename to see the ... ?  What tool are you using to view the file name, and what exactly is the "file name" in this case - a string variable in your program?  A property on the ZipFile object?  something else?

I can't imagine the problem but I think maybe the variables do not hold the values you think they do.  There's an assumption you are making which seems safe and correct but isn't.   Do you know how to run your app in the debugger?  Maybe check the value of the filenames(0) and filenames(1) things, in the debugger, during a run.

Good luck!

Sep 22, 2009 at 2:10 PM
Edited Sep 22, 2009 at 2:11 PM

The problem seems to happen with with UNC paths (not local).   If I use a local path C:\ instead of \\server\share it works with variables. 

With \\server\share in a foreach loop with variables.  I am getting the path from a database.  If I hard code the \\server\share it works correctly.  I have stepped through the code with debugger and verfied the paths by copy and pasting the values into windows explorer.  I know it is correct.

here is one of the for each statements it is failing on:

Using ZIp As New ZipFile

       HttpContext.Current.Response.BufferOutput = False
       HttpContext.Current.Response.ContentType = "application/zip"
       HttpContext.Current.Response.AddHeader("content-disposition", "attachment; filename=" + archiveName)
       Using dataReader As IDataReader = db.ExecuteReader(command)

       While (dataReader.Read())        
         Zip.AddFile(dataReader("FileDirectory") + "\" + dataReader("FileName"), "")
       End While
      End Using
End Using

I am using winrar to view the archieve.  It also fails with Windows XP built in zip handler. 

Winrar results:
The zip is the correct size.  The files inside the zip show the correct size, but the Type shows "File ???"  The filename should be 0_3boxes.jpg, but it shows it as 0_3boxes.jpg ...

Windows XP Zip Handler:
The compressed (zipped) Folder is invalid or corrupt.

The problem does not exist if I use a local path in the database.  I think maybe the files are not being copied or the operation is timing out before the files are completely copied. 

Sep 22, 2009 at 2:20 PM

If the files did not exist, the zip class would through an exception.

Sep 22, 2009 at 2:32 PM

That why you need breaks when you code.  The database variable had an extra 100 spaces in it.  A simple trim() statement fixed that. 

Sep 22, 2009 at 3:53 PM

Great, glad you found it.

I'm trying to decide whether DotNetZip should do the Trim() for you or not.  At this point I'm not sure.  A filename on Windows cannot end with a space.  I'm going to think about this a little.


Sep 22, 2009 at 3:55 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Sep 22, 2009 at 4:53 PM

I was joining strings together to form a path.   filepath + "\" + filename.   I needed to trim the filepath and filename variables.  It should be left to the user of the library to trim the strings.

Thanks for your great work on the library and your help.