#448 Acxrypt Comand Line Problems

open
nobody
None
5
2012-01-14
2012-01-14
Rich
No

Recently I tried to run an encrypt from a BAT File (command line mode). I had two problems:
1. After issuing the command line AXCRYPT from within a bat file with other commands following, return from AXCRYPT is IMMEDIATE BEFORE the files are actually encrypted. I can get around this by issuing a SET /P to wait until I respond to it after checking manually to see if encrypt did its job. Should return from the AXCRYPT command not be done until AFTER the encrypt process is complete? If I issue the CALL command instead, specifying AXCRYPT on it, would I then wait until completions?

2. Also during one of my command line encrypts or decrypts from within a .BAT or .CMD file, AxCrypt failed and briefly just displayed a failure message. I figured the message wasn't a concern at the time since I could just forage on with my testing. Now the problems really started. I am encrypting and decryting all files in a directory and all subdirectories. The interactive interface always works. However, after the failure and about 6 hours of debugging, I found a leftover AXX###.tmp file which apparently had information re files. It caused even a XCOPY or COPY of already decrypted files (source) to a new TARGET directory to contain both unencrypted files as desired, but also ancrypted duplicates with .AXX suffix. Evey time I looked at the resulting target it had BOTH the encrypted and decrypted file in in. Obviously, erasing all AXX*.tmp files cleared everyhitng up (except for the mess it made). You might want to be sure all AXX*.tmp files are deleted after ANY error.
3. Is there parameter I can put on the AXCRYPT command to collect detailed bug data?
4. I there a better, more detailed description of command line use. Specifically including when return is made from command and possible return codes to check? Also, some of the switches (parameters) are not self-explanatory.

I have built a pretty complete backup cmd file that periodically backs up all my critical files, annully merges the first-level backup into a master file, and then creates an incremental backup of the master onto CD (at the moment). A correctly working command line AxCrypt is important (especially question 1 above).

Thank you.

Discussion

  • Rich
    Rich
    2012-01-14

    Ignore Problem 1 - This was my error. I missed a back slash in a directory name and AxCrypt ignored it not being correct. Probem 1 was fixed.

    Problem 2 update: The problem reoccurred without any noticeable failure of AxCrypt this time. Apparently, the temporary dataset it uses is corrupted. I have been testing over and over DECRYPTS and XCOPY. Basically, I copy all files in all subdirectories on a Storage Key device to my main PC into a directiry \DMKBU which desn't already exist. The XCOPY copies the encrypted files correctly. Then I Decrypt \DMKBU files for other processing down the line. I am using the following command:
    "%ProgramFiles%\Axantum\AxCrypt\AxCrypt" -b 2 -m -d -a "%HOMED%\DMKBU\*.axx" -t
    I can test this 4-5 times, each time starting with no \DMKBU (I delete it each time before test) and decrypting the resulting \DMKBU and the final result is \DMKBU with the decrypted files ONLY. Then all of a sudden, WHAM. I do the process and I end up duplicate of the same files, one encrypted and one decrypted). I f I cancel the task AxCrypt, it deletes the AXX*.tmp file also. After which I can continue testing. It appears that the .tmp dataset is used the entire time AxCrypt process is running and each issuance of AxCrypt will use the same .tmp dataset. Any ideas on how I can further capture this error's details? Any idea what in the temporary file might make AxCrypt decrypt KEEP both encrypted and decrypted files? I wish I could copy/display the .tmp file, but the process owns it and all attempts to look at it fail because it owned by AxCrypt, which deletes it when it ends whenever that is.

     
  • Hello,

    I'm a bit confused. However, I have recently attempted to fix an issue where more or less randomly encryption or decryption apparently fails, typically with an error message box though. If you e-mail me via regular e-mail, I can send you a beta version to test.

    I'm a bit confused about your description of the 'axx*.tmp' situation I'm afraid so I can't really say anything about that.

    Svante

     
  • A bit late in answering... However, the axx*.tmp file, just where are you finding it? If it's in %TEMP%\AxCrypt it's just what AxCrypt uses for internal memory allocation and should be locked for the duration.

    Remember to use start/Wait when running AxCrypt from a .bat file, otherwise you may get unexpected results when the .bat-script continues and AxCrypt is continuing to run in the background. AxCrypt is a Windows GUI program, despite the fact that it has a command line as well, so you need to explicitly wait.