Using CABARC to backup/compress files

[JavaMonkey]

I read FAQ 184-145 a while back and thought the concepts there of using CABARC would be very useful. I'm implementing it now in a new app, but I'm using it for a slightly different purpose. I've always envied Access developers for one reason: they can put all their data in a single MDB (I think that's the extension?) file. Those of us using VFP have to create dozens of files...dbf, fpt, cdx, dbc, etc. In most ways, that's better for us as developers but there's one horrible flaw: getting users to deal with all the files properly. They have to be persuaded to back up a whole folder of data instead of simply copying one file and then restore ALL the files together as one unit if a restore is needed. But, human nature being what it is, some user will undoubtedly make a mistake on a customer and decide to restore only customer.dbf from last week...thereby crashing all the links to invoices of new customers as well as losing the matching CDX and FPT files (just one scenario but I think everyone can imagine many other similar situations).

Anyway, I thought I'd try using CAB type files as the main storage medium with this app, which will have relatively small numbers of records (perhaps 2000 or so at most) so they will compress pretty fast with CABARC. When the app starts, it extracts all the database files from the CAB into a 'working' folder...when it shuts down, it compresses the files back into the CAB. The user never really knows that his/her data file is actually 33 separate files...he or she can store the single CAB file under any preferred name in any location.

However, I've run into a slight problem...CABARC is faster than my OS/hard drive! I've run the extraction routine with some debug stuff to test what's happening and it appears that WinExec reports back a successful extraction of all files and my app proceeds on to the next few lines of code which open the database...only to report that the DBC doesn't exist. It does however exist in the 'working' folder and if I use a wait window or suspend execution and then click resume in the debugger, all is fine. It seems like VFP is racing ahead in code faster than the hard drive can finish writing the extracted files to the folder, or something like that. I put in a do while loop to flash a counter in a wait window nowait to see a bit more detail...the counter hits about 250 iterations before VFP can see the extracted DBC (using file() to confirm that the DBC is there. The [/b]do while[/b] loop is a workaround...letting VFP do nothing but count upward until the files are written to disk...but it seems like a kludge. Is there any better way to do this? Any way of running WinExec or ShellExecute and making it wait til the disk writes are complete before sending back the result code (at which point VFP program execution continues)?

 

[ChrisRChamberlain]

JavaMonkey

Although cabarc.exe has terminated the actual .cab file is not complete.

You can check as whether the file is complete by attempting to opening it as follows where lcFileName is the name of the relevant file :-

DO WHILE .T.
[tab]lnNo = FOPEN(lcFileName,0)
[tab]IF lnNo = -1
[tab][tab]FCLOSE(lnNo)
[tab]ELSE
[tab][tab]FCLOSE(lnNo)
[tab][tab]EXIT
[tab]ENDI
[tab]INKEY(0.5)
ENDD

The DO WHILE.. loop prevents you from proceeding until such time as the file is complete.

FAQ184-145 is somewhat ancient now - I would suggest you use the WinAPI call CreateProcess() as opposed to WinExec(), which remains included for 16 bit compatability.

FAQ184-2483 - the answer to getting answered.​

Chris

http://www.pdfcommander.com

http://www.pdfcommander.co.uk

 

[JavaMonkey]

Thanks for the reply. I'll give your do while a try...I think it may be better than mine which uses file() to check if the CAB has been fully extracted and written to disk. After I'm sure all is working well, I'll work on moving the WinExec function to CreateProcess. Too bad there doesn't seem to be a parameter to pass to it telling it to delay reporting the result code back to VFP until the disk writes are completely finished!

 

[ramani]

Hi Java

Look in this also,

A backup utility code.
faq184-4318

I was holding this piece of code because I wanted to add many funcions in that. A WinZip command line function, Restore function, auto naming functions etc to name a few, which are all available with me but has to be fished out of my projects striping 'mine' only code so that any one can use that. Hope I find time to post that soon.


ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[ChrisRChamberlain]

JavaMonkey

FILE() will correctly report the existence of a file, but not whether or not it's complete.

Using CreateProcess() will ensure that control remains with CABARC until such time as CABARC terminates which is in part what you are seeking - if you use ShellExecute() as an alternative, FI, control immediately returns to VFP once CABARC is instantiated.

Either way you are going to need the DO WHILE... loop to ensure the .cab file is complete.

You can also use the same technique to ensure unzipped or extracted files are complete.

FAQ184-2483 - the answer to getting answered.​

Chris

http://www.pdfcommander.com

http://www.pdfcommander.co.uk

 

[JavaMonkey]

Thanks, Ramani for the new FAQ about using Windows Script Host to run CABARC. In the past, I've avoided WSH for what was apparently an entirely erroneous assumption. I've been thinking it was an optional 'extra' in Windows which might or might not be installed, similar to Paint or Character Map. I didn't want to rely on something that might not be present in all systems. However, after your FAQ, I visited Microsoft's WSH page (

http://msdn.microsoft.com/library/en-us/script56/html/wsoriWindowsScriptHost.asp)

and it looks like WSH has been integrated into the OS since Win98. So, I will give this a try! I like that the Run method has the WaitOnReturn parameter to ensure that CABARC has completely finished executing.