Hi! I have been compressing programs on a Win98SE system with a 2.1GB hard drive using 7Zip and creating batch files to decompress them, wait for the user to finish using them and then recompressing them. Now, I have two options: either create a program to automate the process or do it myself. If anybody out there is interested in this, I may create the program. Are you interested?

On Thu, 26 Aug 2021 13:30:01 -0700 (PDT), Harry Potter wrote:
> Hi! I have been compressing programs on a Win98SE system with a 2.1GB
> hard drive using 7Zip and creating batch files to decompress them, wait
> for the user to finish using them and then recompressing them. Now, I
> have two options: either create a program to automate the process or do
> it myself. If anybody out there is interested in this, I may create the
> program. Are you interested?

Since you seems to deliberatly post off topics to multiple newsgroups, are
you interrested on being plonked?

On Thursday, August 26, 2021 at 9:29:24 PM UTC-4, JJ wrote:
> On Thu, 26 Aug 2021 13:30:01 -0700 (PDT), Harry Potter wrote:
> > Hi! I have been compressing programs on a Win98SE system with a 2.1GB
> > hard drive using 7Zip and creating batch files to decompress them, wait
> > for the user to finish using them and then recompressing them. Now, I
> > have two options: either create a program to automate the process or do
> > it myself. If anybody out there is interested in this, I may create the
> > program. Are you interested?
> Since you seems to deliberatly post off topics to multiple newsgroups, are
> you interrested on being plonked?
I'm sorry. I thought this was on topic, as it's about Win32. :(

On Fri, 27 Aug 2021 04:17:03 -0700 (PDT), Harry Potter wrote:
> On Thursday, August 26, 2021 at 9:29:24 PM UTC-4, JJ wrote:
>> On Thu, 26 Aug 2021 13:30:01 -0700 (PDT), Harry Potter wrote:
>>> Hi! I have been compressing programs on a Win98SE system with a 2.1GB
>>> hard drive using 7Zip and creating batch files to decompress them, wait
>>> for the user to finish using them and then recompressing them. Now, I
>>> have two options: either create a program to automate the process or do
>>> it myself. If anybody out there is interested in this, I may create the
>>> program. Are you interested?
>> Since you seems to deliberatly post off topics to multiple newsgroups, are
>> you interrested on being plonked?
> I'm sorry. I thought this was on topic, as it's about Win32. :(

I'm sad that is all you can see.

Harry Potter,

> ... to automate the process ...

Which proces are talking about ? And /how/ do you think you can automate
it ?

If that "automate" is what I think it is than I don't think you can. For
multiple reasons. Like under Windows the program, its supporting DLLs,
configuration and userdata can be stored at different locations, with the
configuration data not even being stored in a folder.

IOW, the /best/ you would be able to do is to ask the user for all those
places - hoping you/the user knows them ofcourse - and generate a batchfile
from that. Or at least knows well enough so that the next unpack will
result in something that can actually be run and having all the data the
user created last time.

And by the way: I hope you do realize that every (re)packing has a chance of
failing, meaning you will need to thoroughly check if everything went OK (if
that can be done in a batchfile) before deleting the origional files, or
stand loosing *all* of it.

> If anybody out there is interested in this

Because of the above mentioned chance of losing everything I've never
considered using a disk compression program or anything else that
recompresses the same files on a regular basis. So no, not interrested.

Regards,
Rudy Wieser

P.s.
When you start a Windows program there is no guarantee that the batchfile
will wait for the program to end before continuing with the next line.

I thank you for your honesty. The automation is simply compressing the application and writing the batch file to temporarily decompress the application. I can use PAUSE to wait for the user to finish using the application and press a key in the window.

Harry,

> I thank you for your honesty.

I have no reason to lie to you, as it would benefit neither me nor you.

> The automation is simply compressing the application and
> writing the batch file to temporarily decompress the application.

I did not consider the first compression, but yes, that is what I thought
you where after.

> I can use PAUSE to wait for the user to finish using the application
> and press a key in the window.

Yes you can. But that doesn't really leave much automation, now does it.
:-)

Also, do check what happens when you forget to press a button in that window
before you tell Windows to shut down. There is a chance that the
recompression will than simply not take place, resulting in that the next
time the users modified but not-stored files will b overwritten by old
copies. There is also a possibility that the packing process will be
started, but possibly forcefully killed because it takes too long.
Definitily not good.

Regards,
Rudy Wieser

On Saturday, August 28, 2021 at 1:57:18 PM UTC-4, R.Wieser wrote:
> Harry,
> > I thank you for your honesty.
> I have no reason to lie to you, as it would benefit neither me nor you.
> > The automation is simply compressing the application and
> > writing the batch file to temporarily decompress the application.
> I did not consider the first compression, but yes, that is what I thought
> you where after.
It is not necessary, but I thought it may help others. Or, I could post one example batch file for others to edit and use. Unfortunately, 7Zip doesn't always work on my Win98SE system, and, sometimes, I have to choose the Deflate technique on a .zip file. It works, then.

> > I can use PAUSE to wait for the user to finish using the application
> > and press a key in the window.
> Yes you can. But that doesn't really leave much automation, now does it.
> :-)
>
> Also, do check what happens when you forget to press a button in that window
> before you tell Windows to shut down. There is a chance that the
> recompression will than simply not take place, resulting in that the next
> time the users modified but not-stored files will b overwritten by old
> copies. There is also a possibility that the packing process will be
> started, but possibly forcefully killed because it takes too long.
> Definitily not good.
>
It doesn't delete the compressed file during use, but if it is interrupted during recompression, the compressed file will be corrupted. Of course, if 7Zip returns an error, I could design the batch files to skip the delete step. I don't remember if I did that right now, though, as I'm not in front of the Win98SE computer--it is at my mother's house, and I'm not there right now.

> Regards,
> Rudy Wieser

Harry,

> Unfortunately, 7Zip doesn't always work on my Win98SE system,
> and, sometimes, I have to choose the Deflate technique on a .zip file.

On an archive you packed up yourself, or just on archives you downloaded ?
In the first case thats odd, as you would expect that 7Zip will be able to
unpack what it has packeded itself ...

> It doesn't delete the compressed file during use,

I didn't think you would. But in the first case I described that the next
time you start the unpack-wait-repack cycle it will unpack a file from the
archive, and by it overwrite the newer(!) file thats still on disk because
it wasn't packed due to the shutdown of the machine.

> but if it is interrupted during recompression, the compressed file
> will be corrupted.
....
> I could design the batch files to skip the delete step

Yes, you could. But it would not help, as the "that process takes to long
to finish, just kill it" would most likely be aimed at the batchfile itself
/and/ any childprocesses it started. IOW, the re-compress line (which
could take too long) would be the last one the batchfile would be executing.
Though that ofcourse means that any "delete those files" commands afterwards
won't be executed either (you will still have the origionals). :-)

And assuming that 7Zip is not stupid it will not overwrite the existing
(old) archive, but create a temporary-named new one and only when it
finishes succesfully attempt to remove the old archive and give the new
archive its name. IOW, when the packing process is killed (or just fails)
you should still have a working (but old) archive.

And when that happens (you keep the working old archive) you have a same
problem as with the first case I described : the archive than could have
older versions of the newer versions that you still have on disk, and the
next unpack-wait-repack cycle would overwrite those newer files.

But maybe the 7Zip program has a comandline option instructs them *not* to
overwrite target files that already are on disk and are newer.

I also seem to remember a commandline option that automatically deletes the
sources of all just-achived files after finishing successfully. Maybe 7Zip
has that one too. Saves several batchfile steps.

Regards,
Rudy Wieser

On Sunday, August 29, 2021 at 4:07:03 AM UTC-4, R.Wieser wrote:
> Harry,
> > Unfortunately, 7Zip doesn't always work on my Win98SE system,
> > and, sometimes, I have to choose the Deflate technique on a .zip file.
> On an archive you packed up yourself, or just on archives you downloaded ?
> In the first case thats odd, as you would expect that 7Zip will be able to
> unpack what it has packeded itself ...
On an archive I packed.

> > It doesn't delete the compressed file during use,
> I didn't think you would. But in the first case I described that the next
> time you start the unpack-wait-repack cycle it will unpack a file from the
> archive, and by it overwrite the newer(!) file thats still on disk because
> it wasn't packed due to the shutdown of the machine.
I'm responsible enough not to kill the batch file during the recompress operation. :)

> > but if it is interrupted during recompression, the compressed file
> > will be corrupted.
> ...
> > I could design the batch files to skip the delete step
> Yes, you could. But it would not help, as the "that process takes to long
> to finish, just kill it" would most likely be aimed at the batchfile itself
> /and/ any childprocesses it started. IOW, the re-compress line (which
> could take too long) would be the last one the batchfile would be executing.
> Though that ofcourse means that any "delete those files" commands afterwards
> won't be executed either (you will still have the origionals). :-)
>
Again, I'm responsible enough. :) BTW, I have compressed some large programs (i.e. >=8MB compressed), so that would be a concern.

> And assuming that 7Zip is not stupid it will not overwrite the existing
> (old) archive, but create a temporary-named new one and only when it
> finishes succesfully attempt to remove the old archive and give the new
> archive its name. IOW, when the packing process is killed (or just fails)
> you should still have a working (but old) archive.
>
I think it is smart enough. However, when I decompress an archive across drives, the result is in the wrong drive.

> And when that happens (you keep the working old archive) you have a same
> problem as with the first case I described : the archive than could have
> older versions of the newer versions that you still have on disk, and the
> next unpack-wait-repack cycle would overwrite those newer files.
>
I don't understand. :(

> But maybe the 7Zip program has a comandline option instructs them *not* to
> overwrite target files that already are on disk and are newer.
>
Again, I don't understand. :(

> I also seem to remember a commandline option that automatically deletes the
> sources of all just-achived files after finishing successfully. Maybe 7Zip
> has that one too. Saves several batchfile steps.
>
Okay. Let me check.

Harry,

> On an archive I packed.

Thats certainly odd.

> I'm responsible enough not to kill the batch file during the recompress
> operation. :)

The thing is that its not your choice anymore when you forget (due to a
moment of distraction?) to unpause before telling Windows to shut down.

Its like those people who /never/ forget to take the key with them when they
leave the house - up until the moment that they do, and than do that without
their wallets or their phones (the worst possible circumstances). :-| :-)

Or, put otherwise : aim for the best, but recon with the worst.

> I think it is smart enough. However, when I decompress an
> archive across drives, the result is in the wrong drive.

Really ? Never had that problem using ARJ, ZIP and a few others. Normally
you can provide both the source archive-file as wel as the target folder as
arguments.

https://stackoverflow.com/questions/31463641/how-to-unzip-a-file-to-a-target-folder-using-7-zip

>> And when that happens (you keep the working old archive)
....
> I don't understand. :(

It goes this way :

1) You start the batchfile which unpacks the archive, which will extract the
file "a.txt" to the disk. If the file "a.txt" already exists on the disk it
will overwrite it (default extraction settings).

2) You edit the file "a.txt"

3) For some reason the repacking does *not* happen.

You now have a "a.txt" still on the disk, which is changed and /newer than
the one in the archive/.

The next time you start the batchfile the extraction of the older(!) "a.txt"
file from the archive will overwrite the newer(!) "a.txt" file that was
still on the disk. Poof!, all the previous hard work on the "a.txt" file
that was still on the drive is erased. :-(

>> But maybe the 7Zip program has a comandline option instructs them *not*
>> to overwrite target files that already are on disk and are newer.
>>
> Again, I don't understand. :(

It could go something like this : when 7Zip is told to extract the file
"b.jpg" it could first check if that "b.jpg" is /already present/ on the
disk, and if so check if the datetime of the file in the archive is older
than that of the file on the disk, and skip extraction if so.

7Zip does have /something/ like it, just not with the "check which file is
newer" part :

https://documentation.help/7-Zip/overwrite.htm

See the "-aos" switch.

>> I also seem to remember a commandline option that automatically deletes
>> the sources of all just-achived files after finishing successfully.
....
> Okay. Let me check.

https://documentation.help/7-Zip-18.0/sdel.htm

See the "-sdel" switch. Remark : Seems to need 7Zip v18.

Regards,
Rudy Wieser

What I have is good enough for my needs. I can post an example file here, but my WIn98SE computer is at my mother's house, and the earliest I *might* be there is next weekend.

My batch files are so far reliable--after finding a technique that works--and, if 7Zip returns an error, I can skip the delete-after-recompression step. Then, I can figure out where the error is and try to recompress the software manually. Is anybody interested in doing this? I *could* post an example batch file online or create a program to create the batch file and compress the applications for you.

Harry,

> if 7Zip returns an error, I can skip the delete-after-recompression step

Thats a very good change/addition. :-)

> and try to recompress the software manually

I would suggest you to try to combine that with your current batchfile.
Having to remember "special stuff" that you seldom need often takes extra
"how the heck did I do that again?" work.

For instance, when you use the "no overwrite on uncompress" 7Zip argument
you could simply run your uncompress-wait-compress batchfile again.

If you also add a "don't uncompress or wait" argument to your batchfile you
can use it for doing the first compress as well as a fresh
recovery/recreate.

> I *could* post an example batch file online

Another good idea. That way we could possibly spot stuf that won't quite
work as you would expect it to, as well as making it easier to suggest stuff
and where to add it.

Regards,
Rudy Wieser

On Wednesday, September 1, 2021 at 3:59:12 AM UTC-4, R.Wieser wrote:
> Harry,
> > if 7Zip returns an error, I can skip the delete-after-recompression step
> Thats a very good change/addition. :-)
Thank you.

> > and try to recompress the software manually
> I would suggest you to try to combine that with your current batchfile.
> Having to remember "special stuff" that you seldom need often takes extra
> "how the heck did I do that again?" work.
>
I already did. The manual compression will be done if and only if the batch file failed to recompress the program properly.

> For instance, when you use the "no overwrite on uncompress" 7Zip argument
> you could simply run your uncompress-wait-compress batchfile again.
>
I *could* do that.

> If you also add a "don't uncompress or wait" argument to your batchfile you
> can use it for doing the first compress as well as a fresh
> recovery/recreate.
I'd rather do it manually in that case instead of having the batch file accept the argument, as it would be easier than opening the command line, switching folders and running the batch file with the switch.

> > I *could* post an example batch file online
> Another good idea. That way we could possibly spot stuf that won't quite
> work as you would expect it to, as well as making it easier to suggest stuff
> and where to add it.
>
Okay. I need to go to my mother's house for that, as the Win98SE computer is at my mother's house.

Harry,

> I already did. The manual compression will be done if and only
> if the batch file failed to recompress the program properly.

I get the feeling that your definition of "manual recompression" is
different from mine ...

>> For instance, when you use the "no overwrite on uncompress" 7Zip
>> argument you could simply run your uncompress-wait-compress
>>batchfile again.
>
> I *could* do that.

:-) All I have given you is a "have you thought of {this}" suggestion.
They are options for you to consider. Its fully upto you if you want to use
them.

> I'd rather do it manually in that case instead of having the batch file
> accept the argument, as it would be easier than opening the command
> line, switching folders and running the batch file with the switch.

Als long as all the files are in a single folder that will ofcourse work.
Anything more complex and its not a question of /if/, but /when/ you will
forget something when doing a manual recovery.

But have you already thought of creating a "recovery" batchfile ? One
which does nothing more that calling the actual batchfile with the
"recovery" switch ? Just give it a good name so its not directly
above/under the actual batchfile (so you do not click it by mistake), or
just put them in a "recovery" folder.

But do notice that when you add the "do not overwrite on decompress" 7Zip
switch when you decompress than a "manual recovery" becomes as simple as
running the batchfile again, and you would have little need for a batchfile
switch. :-)

Regards,
Rudy Wieser

On Wednesday, September 1, 2021 at 4:20:37 PM UTC-4, R.Wieser wrote:
> Harry,
> > I already did. The manual compression will be done if and only
> > if the batch file failed to recompress the program properly.
> I get the feeling that your definition of "manual recompression" is
> different from mine ...
My definition of "manual" is using the 7Zip file manager to do it.

> >> For instance, when you use the "no overwrite on uncompress" 7Zip
> >> argument you could simply run your uncompress-wait-compress
> >>batchfile again.
> >
> > I *could* do that.
> :-) All I have given you is a "have you thought of {this}" suggestion.
> They are options for you to consider. Its fully upto you if you want to use
> them.
> > I'd rather do it manually in that case instead of having the batch file
> > accept the argument, as it would be easier than opening the command
> > line, switching folders and running the batch file with the switch.
> Als long as all the files are in a single folder that will ofcourse work.
> Anything more complex and its not a question of /if/, but /when/ you will
> forget something when doing a manual recovery.
>
Some of my programs decompress to two or more folders, but I use separate commands for each.

> But have you already thought of creating a "recovery" batchfile ? One
> which does nothing more that calling the actual batchfile with the
> "recovery" switch ? Just give it a good name so its not directly
> above/under the actual batchfile (so you do not click it by mistake), or
> just put them in a "recovery" folder.
>
Actually, I have my batch files set up so that, if that happens, 7Zip will ask to overwrite the files first. I could just press Ctrl-c and N at the prompt to terminate the batch file.

> But do notice that when you add the "do not overwrite on decompress" 7Zip
> switch when you decompress than a "manual recovery" becomes as simple as
> running the batchfile again, and you would have little need for a batchfile
> switch. :-)
>
Thank you.

Harry,

> My definition of "manual" is using the 7Zip file manager to do it.

I already got that feeling. My definition of it was more in the direction
of having to enter a commandline switch by hand (instead of automatically
checking if a recovery might be needed and asking the user if they agree and
want to continue with it).

>> Anything more complex and its not a question of /if/, but /when/ you
>> will forget something when doing a manual recovery.
>>
> Some of my programs decompress to two or more folders, but I use
> separate commands for each.

And thats just a /simple/ "it does more". :-)

> 7Zip will ask to overwrite the files first.

Ah yes, ofcourse. I forgot all about that ... :-|

Regards,
Rudy Wieser

I'm sorry about the SPAM in this post, but I thought this would be an interesting use for one of my programs. It is called Template Creator for Windows. It can be used to create the new batch files for the new programs, but I admit to just copying an old file, as they're all in the same place. ;) It is at https://sourceforge.net/projects/tmpcreat/files/. Enjoy!

I have good news: I should be going to my mother's house tomorrow evening. :) Then, I will be able to upload an example batch file.