Insufficient space error when there appears to be more than sufficient space

[pguild]

I am able to compile a Winbatch script, but when I run it I get confusing error messages described below.
(I have simple .jpg screenshots of these error messages, but for some reason, they do not pass the security check of this forum.)

The first error message is:
---------------------------------
Determined.txt
Required DLL File could not be created.
Insufficient disk space exists on drive to
write the DLL file above.  Approx 400K needed. 
---------------------------------
(NOTE: no DLL file is listed above, just a text file. Also, 14.5 GB of free disk space is available)
-----------------
Next, this error message appears:
---------------------------------
WIL Extender Error: 10143 ExtractAttachedFile Error
finding or extracting specified file
---------------------------------
The code asking for extraction is as follows:
   ;Extract other files if they don't already exist
   rc = 0
   files[0] = "prompts.txt"
   files[1] = "BigArticle.txt"
   files[2] = "Determined.txt"
   files[3] = "Editor.txt"
   files[4] = "Encouraging.txt"
   files[5] = "Fitness-enhancing.txt"
   files[6] = "Inspirational.txt"
   files[7] = "MakePrompt.txt"
   files[8] = "Oneliners.txt"
   files[9] = "people.txt"

   foreach file in files
      if ! FileExist(file)
         rc = ExtractAttachedFile(file, file)
      endif
   next

I've tried running the application on multiple drives all of which have more than adequate disk space, and I get the same error messages.
NOTE: previously, I was able to compile and run the application without these errors, and I think I made no changes to the script.
The Winbatch error about not being able to extract the required DLL without listing the DLL above is confusing.
Also, the required DLL was actually extracted as you can see from one of the screenshots.

How can I fix this? Thanks for your help.

[td]

Without knowing details it is difficult to suggest a cause because there could be many. The only suggestion is to recompile the script after ensuring your compiler settings are all as intended and have not changed from the last time the compiled script worked. You might want to make doubly sure that the `Skip auto-extraction of "Extender" and "Other Files"` option is checked.

Also, it should be self-evident that the reference to "DLL" in the error message is not significant because the error message mentions the file causing the problem and none of the files you are extracting has a "DLL" extension. Of potential significance is that the file mentioned in the error message is the first to be extracted by the ExtractAttachedFile function.

[pguild]

What compiler settings should I use?  To my knowledge, I have not changed the compiler settings.  Does it make sense that Winbatch is complaining not being able to extract a DLL file when actually the DLL file *was* extracted?

Something is really off when Winbatch thinks there is not enough space when there is plenty! Could this possibly be a bug that needs fixing -- in Windows 11 or, ahem, elsewhere?

I am about ready to throw in the towel on this extraction business since it does not work and I don't know how to fix it.  Earlier I just gave the users a zip file and asked them to unzip all the files needed and it worked, although it is cumbersome.

**Also** please let me know why simple .jpg file in my attached files are flagged by this Forum.

[JTaylor]

Do you happen to be extracting and running any scripts in that directory?  If so, make sure they are compiled as a Small Exe as they are trying to write over the main winbatch DLL of the extracting script when they launch.

Jim

[td]

What compiler settings should I use?  To my knowledge, I have not changed the compiler settings.  Does it make sense that Winbatch is complaining not being able to extract a DLL file when actually the DLL file *was* extracted?

Something is really off when Winbatch thinks there is not enough space when there is plenty! Could this possibly be a bug that needs fixing -- in Windows 11 or, ahem, elsewhere?

I am about ready to throw in the towel on this extraction business since it does not work and I don't know how to fix it.  Earlier I just gave the users a zip file and asked them to unzip all the files needed and it worked, although it is cumbersome.

**Also** please let me know why simple .jpg file in my attached files are flagged by this Forum.

As mentioned in my original post on this topic make sure the `Skip auto-extraction of "Extender" and "Other Files"`  setting is selected in your compiler settings. And it is not at all likely that your error message is a "bug" in WinBatch. WinBatch simply uses a single Windows API call to determine available disk space.  Only 14.5 GB of disk space is suspect, however.

There are many approaches to problem-solving. Some are more sophisticated than others.

Note that this forum has both total size and content restrictions on images and other attachments. 

[td]

Do you happen to be extracting and running any scripts in that directory?  If so, make sure they are compiled as a Small Exe as they are trying to write over the main winbatch DLL of the extracting script when they launch.

Jim

The compiler checks for the existence of the interpreter DLL and does not extract it if it already exists. It would also generate a different error if it could not write the DLL because it was locked by another process. The error is the result of a call to the ExtractAttachedFile function and the error message in the first post of this thread indicates the problem text file. Any required interpreter DLL extract would have already occurred before the first call to ExtractAttachedFile. This is known because the function is part of a script and the script would not be executing without the interpreter DLL. 

[JTaylor]

Okay.  Maybe I didn't word my question very well???  I run into this issue sometimes when trying to launch a script where I already have the script running.  Probably something with my compiler settings or launch sequence.   It is what made me post my question.   I will withdraw...

Jim

[pguild]

"WinBatch simply uses a single Windows API call to determine available disk space.  Only 14.5 GB of disk space is suspect, however."

What is meant by "Only 14.5 GB of disk space is suspect, however."?   If WinBatch is using a single Windows API call, why is it saying that there is insufficient disk space? Is 14.5 GB more than 400K? About 400K of disk space is required according to the error message.

The Winbatch error message itself seems to be erroneous for two reasons.
1. The error message says: "Required DLL could not be created. Insufficient disk space available on the drive to write the required DLL file above. Approx 400K needed"  (But no DLL file is referenced, and actually the DLL file was extracted." Does it make sense for Winbatch to be issuing such an error?

2. Also, 14.5 GB is certainly more than enough disk space if only about 400K is needed.

By the way, no matter how much space is available, I get the same apparently erroneous error message. With 1 or 2 terabytes of space available, I get the same error message.

It will be fascinating to discover why this error message is tormenting me and to banish it.

[pguild]

UPDATE: When I get rid of the ExtractAttachedFile code and uncheck `Skip auto-extraction of "Extender" and "Other Files"` the needed .txt files are extracted just fine, and the application runs without the error messages. Why is that? There is not enough disk space for the ExtractAttachedFile code, but when the files are auto-extracted there is plenty of space. Does that make sense?

The reason I started using ExtractAttachedFile is because I didn't want to overwrite those txt files if they already existed.  Now, I need to warn users to back up the txt file if they are installing a new version of the application and they want to preserve the txt files.

[td]

You seem to be preoccupied with the "DLL" term used in the error message. Its presence has nothing to do with the issue at hand. Just change it to "file" without "DLL" in your mind since you find it so confounding...

The reason 14.5 GB of disk space is suspect is that is very little space for any drive on a modern system and can cause problems. However, there is no way of knowing if this was related to the issue in this case. It was just something to potentially be looked into. You seem to indicate that it is not part of the problem and that is an example of how to narrow the search for a cause.

As previously mentioned the WinBatch executable uses a single Windows API call to determine available disk space. In fact, the exact same code is used for automatic extraction and extraction via ExtractAttachedFile. The only difference is automatic extraction occurs before your script has a chance to run and do anything that might affect the extraction process.

You seem to have chosen your pet explanation whether or not it has any connection to the reason for the issue. However, the list of possible explanations is long. It would require more information to narrow those possibilities. Without that information, it seems an exercise in futility to spend any more time on this topic.

[td]

If you are open-minded enough to want to objectively solve your problem, send the smallest compiled script you can write that reproduces the problem to support@winbatch.com. Make sure to compress the file with the zip format before attaching it to an email message. Somebody will have a look at it.   

[td]

The OP chose not to provide an example compiled script but with some code analysis combined with a couple of assumptions, a bit of system reconfiguration, and some fortuitous guesses; we reproduced the behavior. The bug has been around since 2005 but it is understandable why it was never reported. It required a number of conditions to line up just right.

The simplest workaround is to add a full file path to the file name of ExtractAttachedFile's second or "target-name" parameter.

The problem will be addressed in the next release.

[jmburton2001]

a couple of assumptions, a bit of system reconfiguration, and some fortuitous guesses; we reproduced the behavior.

You failed to mention the ever useful sprinkle of pixie dust and the wave of a magic wand.  ;)

We know your secret!

[td]

Yup. Learned that one from the wizard under the Phrygian cap through Marty.

[kdmoyers]

Well, "the wizard under the Phrygian cap" was certainly a pleasant trip down a rabbit hole.
https://en.wikipedia.org/wiki/Phrygian_cap
Fascinating!

[td]

One of Marty's favorites: https://en.wikipedia.org/wiki/Cheech_Wizard

[kdmoyers]

Another wonderful trip, thanks!