ZipException CreateFileCE Failed

Jun 25, 2009 at 3:37 AM

I am developing a configuration app for a popular Windows Mobile GUI and some of my users are recieving an error that I have not been able to resolve or reproduce.

 

This is the exception they are recieving ...

 

ZipException

CreateFileCE Failed at Ionic.Zip.NetCfFile.SetLastWriteTime(String filename, DateTime mtime)


  at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream outstream, String password)
  at Ionic.Zip.ZipFile.Extract(String entryName, String directoryName, ExtractExistingFileAction extractExistingFile)


  at MS3Config.Form1.UpdatePanelStates()
  at MS3Config.Form1.tabPanels_Paint(Object sender, PaintEventArgs e)
  at System.Windows.Forms.Control.OnPaint(PaintEventArgs e)
  at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
  at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
  at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
  at System.Windows.Forms.Application.Run(Form fm)
  at MS3Config.Program.Main()

 

This is the function that is calling Extract() ...

 public void UpdatePanelStates()
  {

.

.

.
  // open qa_layouts.dat  .. a standard zip file
  ZipFile zip = ZipFile.Read(SpbMS3InstallPath + "\\qa_layouts.dat");
  zip.Password = "b0fm18zq";

  // loop through a eaEntries .. an arraylist of XMLPatcher.Entry objects that each contain a filename to extract from the zip file and parse
  for (int i = 0; i < xmlp.eaEntries.Count; i++)
  {
  XMLPatcher.Entry e = (XMLPatcher.Entry)xmlp.eaEntries[i];

// MS3CTempPath is a directory that already exists

// e.FileName  always exists in qa_layouts.dat

zip.Extract(e.FileName, MS3CTempPath, ExtractExistingFileAction.OverwriteSilently);

.

.
  }
  zip.Dispose();
   
   
 .

.

.

.


  }

 

 

I am using the version 1.8 DLL ..

 

I apologize if this question has been answered but I have not been able to find any information on the error ..

 

Thank you!!

Coordinator
Jun 25, 2009 at 3:35 PM
Edited Jun 25, 2009 at 3:45 PM

I don't think it's been answered; I don't recall having seen a problem like this.

CreateFileCE is failing, but the code does not display the reason why.  I just made a change in the source so that when this problem occurs, a more useful and informative error will be displayed.

Also, it seems like not a critical error.  I will have to think whether I can modify the code to emit a warning if it fails in this situation.

Also - How often does this problem happen?  Can you readily reproduce it?

Jun 25, 2009 at 3:50 PM
Thank you for such a quick reply... I won't have access to the project until this evening but if you have any questions or need a copy of the zip file, let me know.

Thanks again...



From: Cheeso <notifications@codeplex.com>
Sent: Thursday, June 25, 2009 8:35 AM
To: voldeus@gmail.com
Subject: Re: ZipException CreateFileCE Failed [DotNetZip:60585]

From: Cheeso

I don't think it's been answered; I don't recall having seen a problem like this.

SetLastWriteTime is failing, but I don't see an explanation for *why*.

It seems like not a critical error. I think I can modify the code to try to set the time and emit a warning if it fails.

Coordinator
Jun 25, 2009 at 3:54 PM

The improved error message will be in v1.8.3.35, which will be up later today.  If the problem happens readily, then you can run it again and get a better message.  With a better message, we may be able to figure out how to avoid the error. 

Jun 25, 2009 at 5:29 PM
I have not been able to reproduce the error message on my test devices but I will recompile and upload this evening so that one of my users can send me the error text ...

I'll get back to you as soon as possible...



From: Cheeso <notifications@codeplex.com>
Sent: Thursday, June 25, 2009 8:55 AM
To: voldeus@gmail.com
Subject: Re: ZipException CreateFileCE Failed [DotNetZip:60585]

From: Cheeso

The improved error message will be in v1.8.3.35, which will be up later today. If the problem happens readily, then you can run it again and get a better message. With a better message, we may be able to figure out how to avoid the error.

Coordinator
Jun 25, 2009 at 6:11 PM

ok I will stay tuned.

 

Jun 26, 2009 at 2:31 PM

Okay I have a new log file from a user and the exception text is as follows.

 

Exception: Ionic.Zip.ZipException: CreateFileCE Failed (87)
  at Ionic.Zip.NetCfFile.SetLastWriteTime(String filename, DateTime mtime)
  at Ionic.Zip.ZipEntry.InternalExtract(String baseDir, Stream outstream, String password)
  at Ionic.Zip.ZipFile.Extract(String entryName, String directoryName, ExtractExistingFileAction extractExistingFile)
  at MS3Config.Form1.UpdatePanelStates()
  at MS3Config.Form1.tabPanels_Paint(Object sender, PaintEventArgs e)
  at System.Windows.Forms.Control.OnPaint(PaintEventArgs e)
  at System.Windows.Forms.Control.WnProc(WM wm, Int32 wParam, Int32 lParam)
  at System.Windows.Forms.Control._InternalWnProc(WM wm, Int32 wParam, Int32 lParam)
  at Microsoft.AGL.Forms.EVL.EnterMainLoop(IntPtr hwnMain)
  at System.Windows.Forms.Application.Run(Form fm)
  at MS3Config.Program.Main()

 

I assume the number in parentheses (87) is the error number?

A quick glance at WinError.h shows this

 

//
// MessageId: ERROR_INVALID_PARAMETER
//
// MessageText:
//
// The parameter is incorrect.
//
#define ERROR_INVALID_PARAMETER 87L // dderror

 

 Any thoughts? If you need me to have more information about the arguments I am passing to Extract() .. I'll have them posted to the log file and get another copy of it, let me know..

Coordinator
Jun 26, 2009 at 3:36 PM

Yes, the number printed in the message is the Windows error number.   I am investigating.

Coordinator
Jun 26, 2009 at 3:38 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Jun 26, 2009 at 3:54 PM

volDeus, this problem seems to be reliably reproducible?

Does it happen every time?  Can you tell me more about the circumstances under which it occurs?  I have created a workitem :
7944: SetLastWriteTime fails on Compact Framework

I think failure to set the file time should not be treated as a critical error. I don't really understand why it is failing, but regardless, I feel as though it is not worth throwing the exception. As I suggested earlier, I propose to emit a warning in this situation. In the meantime I can continue to investigate and test it. What do you think of this approach?

I am right now producing a special binary to provide this new behavior, and I'd like you to try it out.  I will attach it as a zip to the workitem 7944. Let me know when you have tried it and what your results are.

The warning is wrtten to the StatusMessageTextWriter on the ZipFile instance.  This is a TextWriter that collects status messages as the zipfile is saved, extracted, or read.  If you don't set the StatusMessageTextWriter property, then you will get no messages.  If the failure to set the filetime occurs in this case, then it will be a "silent" failure. Your code will have no indication of any failure.

Jun 27, 2009 at 5:40 AM

Thank you again for your help... The change seems to have resolved the problem in this case.

The exception has been consistent and occured with every execution for those users that experienced it ... As I said, I have not been able to reproduce it on either of my own test devices.  I will post what information I have about the circumstances in the workitem.

As for my opinion of your approach; to answer honestly I would have to know more specifically what is taking place in your code when SetLastWriteTime is called... Adjusting the behaviour as you have does not adversely affect my project in the area where the exception was being thrown...  I worry though, that problems may arise if this "silent" response is given in another area where the time information of an extracted file is critical to my code behaving as expected (or someone else's if you release)... Of course I will simply monitor StatusMessageTextWriter in the areas that require time information, and attempt a work-around, but I wonder if perhaps the new behaviour should not be the default.

 

Coordinator
Jun 27, 2009 at 10:35 AM

It's a very curious case.

I don't like the fact that I really don't know why the failure occurs.  I am less worried about ignoring the failure - it is just setting the time on a file and at best that should be considered a secondary failure condition. As you said there may be some applications that require it, so it is not a non-failure.  Like you I'm not really 100% satisfied with the situation.

If you are capable, it would be nice to do some further research.  Create a custom build of DotNetZip and debug it.  Try different things. Maybe there is a time dimension to this problem.  Maybe delaying 100ms after the file has been closed, but before the time has been set on it, would avoid the problem completely. Maybe there is some other easy avoidance.

In any case I would very much bb interested in the Status messages that come out.  Is it only one file that fails?  Is it the same file for every user?  does it happen with all files, or only files of a certain type, size, or extracting only to a certain store? etc?  Is there something else common among the users that experience it?  Do they have the same type of device?  The same build of Windows CE?  (I am assuming you are running it on Windows CE - true?).  The same kind of memory storage card?  Is it rated "fast enough"?   What if you unset the high-resolution time on the entry before extracting?  (this would cause the library to use the low-resolution time for extraction, rather than the high-res time)   If it were me I would want to understand more about it.   (Can you tell me more about the app in any case?  Just curious.)

Unfortunately, I am not close enough to the app and to the systems to do this troubleshooting and debugging. But I'd be very interested in what you can find on your own.

 

Jun 27, 2009 at 8:17 PM

I definately agree with your wanting to research it further...  I will try what you have suggested and help in any way I can...  I have been gathering information regarding the hardware and OS of the affected users (it is CE, primarily WM6.1 and WM6.5)..  I will post your status information to log files in the next test version as well..  Hopefully, I will be able to stay in close enough contact with the affected users, to update the workitem with their log files as soon as possible.

My application is a "configurator" for a popular Windows Mobile GUI called "Spb Mobile Shell 3" (MS3) ... It's primary function at this time is changing the backgrounds of the different dialogs in "MS3"...

I accomplish this by extracting certain XML files from a password protected archive, editing them, and updating the archive with the edited copy...  If you are interested I can give you copies of the significant code and the archive file...

 

As I said, I will help as much as I can...  I apologize that our discovery process may be a slow moving one...  Especially considering I still have not been able to reproduce the error on my own. (although I will continue to try different configurations)