Winrar Cmd Commands

1 view
Skip to first unread message

Arridano Tillo

unread,
Jul 18, 2024, 9:47:38 PM7/18/24
to knicalagpu

In other words option -ep1 results in omitting everything from path up to last backslash in specified file or folder name on adding the file or folder to the archive which explains the difference on adding a folder without or with backlash at end specified on command line.

winrar cmd commands


Descargar archivo ❤❤❤ https://ssurll.com/2zoTnj



So RAR must search first in the specified folder for a subfolder. If found go into this subfolder and search again for a subfolder. If one is found, go into this subfolder and search for a subfolder. If no one found, add the files in this subfolder into the archive or just the folder name if the subfolder is empty. Then go back to parent folder and continue searching for next subfolder. If none is found, add the files of this subfolder. Then go back to parent folder and continue search for subfolder, and so on.

As you can read, the same procedure is done again and again for each branch of the entire folder tree until all subfolders were processed. This is done using a recursion. The subroutine searching for subfolders calls itself every time a subfolder is found.

Console version Rar.exe supports only creation/extraction of RAR archives. It does not support ZIP archives. This is clearly written in text file Rar.txt at top which is the manual for console version of WinRAR. It would be necessary to use WinRAR.exe instead of RAR.exe to create ZIP archives.

GUI version WinRAR.exe has many commands and switches identical to console version Rar.exe, but there are differences as shown here with -afzip supported only by WinRAR.exe and -ibck instead of -idq to run WinRAR in background which means minimized to system tray instead of in foreground with a visible progress window.

It is advisable to read the help pages in listed order respectively the text file Rar.txt from top to bottom on creating the WinRAR.exe or Rar.exe command line for usage in a batch file or in a shortcut file (*.lnk).

I am trying to code a program that will RAR an a folder that contains many subfolders with files in them. WinRAR allows for command line codes to be sent to control WinRAR through the command prompt (I have this working well). What I want to do, is integrate this command line code through the command prompt into a vi. I have tried using the System Exec.vi, but with very little luck. I have set the path for winrar tools to be present at that directory and I have used the "cmd /c" string before my input so that LabVIEW knows its a DOS command. I keep getting an error message that says " 'winrar' is not recognized as an internal or external command, operable program or batch file." I have tried moving the command line codes to the standard input and even the winrar code to that input as well (this only leaves the "cmd /c" as the command to be sent), still no dice. Any suggestions would be most useful. I can provide my code and a list of the command line codes for WinRAR if you need it. Other zipping programs would be another option to take that I am open to, as long as it can be controlled within the LabVIEW environment and that the compression is best.

can you show the System Exec call or a picture of it? It would be very helpful. I'm sure it will work, but if not you can try to insert your code into a batch file and call this with the System Exec function.

Another option might be the use of the OpenG LVZIP library. It is supported on Widnwos, Mac OS X and Linux so fairly cross platform. It does its work by using an external shared librarey created from the zlib library fromJean-loup Gailly and Mark Adler and and the according ZIP file extension fromGilles Vollant

You can best download the VIPM here and get the oglib-LVZIP library and the necessary support libraries (file and error). VIPM uses this library too as its VI packages are really ZIP files with a specific internal file structure.

I have developed a VI in LabVIEW 8.6 that uses WinRAR command-line tools (passed into the System Exec.vi) to archive data that is held on 5 different networked computers, and stores the resulting .rar files on a server. The VI's executable runs perfectly on my development computer (running WinXP). The data from each of the 5 machines is archived and the .rar files are stored on the server. However, when I move the executable to the server where the .rar files will be stored, and run the executable, the command window flashes on the screen as if the WinRAR commands are being executed, but no data is archived onto the server. No errors are passed out of the System Exec.vi. The Server's OS is Windows Server 2012, and I have placed the Rar and UnRAR .exe's in the system32 folder on the server. The server's firewall is disabled, and it is able to explore to the locations of the data to be arhived. The server is logged in as a domain administrator account.

I tried to work around the issue by creating a batch file containing the above command and then using the System Exec.vi to call this batch file. Again, when I run the batch file manually, it works correctly, but when the System Exec.vi in a LabVIEW executable runs the batch file on the server, I get the same result as descirbed above -- no data is archived onto the server. This batch file method does work on my development computer, and on my company laptop.

My only thought is that there is an issue with access rights. So far the executable works correctly on an older server (Windows Server 2003), the development computer (Win XP), and my company laptop (Win7), but the executable does not archive the data on the Server 2012 server or on another computer running WIndows 7. I have all of these machines logged in as the same domain administrator account, but IT networks are admittedly over my head, so I wanted to check here to see if anyone has seen this issue with WinRAR and/or the System Exec.vi.

When in your EXE was does the standard out, and error out return from the exec? I'd suggest adding debugin indicators so when in an EXE you can see what the output is, along with what the input to the function is.

I had previously put an indicator on the System Exec.vi and there were no errors. Per your suggestion, I did just put an indicator on Standard Output, and the following was returned every time the System Exec.vi was executed:

To double-check the command line command, I manually typed one of the commands passed into the System Exec.vi into the command prompt, and there were no issues (attached: "Manual Execution.jpg). There must be something wrong with my wiring of the System Exec.vi.

To test this, I put together a quick VI using just the System Exec.vi and one rar command (attached: "Single RAR Command.jpg"). This executable runs correctly with no errors on my laptop. There is no message in the Standard Error or the Error Out of the System Exec.vi. The Standard Output of the System Exec.vi on this simple executable says the folowing:

This further leads me to believe that I am not using the System Exec.vi correctly, but I have been succssful in simple commands passed into the System Exec.vi such as "cmd /c dir," and I'm also still curious as to why I can call batch files with the System Exec.vi but not when the batch files contain the "rar" command. Any ideas?

You could also test by using the complete path to the RAR executable. If I am relying on a third-party program like this I tend to track down the install directory myself (either automatically or have the user find it), and save it as part of the configuration. When I go to call the program I then use the full path. This way I am not relying on things like having the program installed in the same directory, or a specific location, or added to the path.

Darin, I took your suggestions and after a little more fighting with it, I was able to an Error Code 2 out of the System Exec.vi. This led me back to searching the forums where I stumbled on the following:

Sure enough, every machine that had been able to run the executable is a 32-bit system. Every machine that has been unable to run the executable is a 64-bit system. I placed the Rar.exe in the C:\Windows\SysWOW64 folder on the server and it works exactly as intended now.

I have a problem finding the correct way to unrar multiple files with the help of Winrar command.
With a button, I managed to unrar them all, but all in the same time. It's not very efficient...
The best solution is to unrar them sequentialy, but I can't find the correct winrar command to do this.

The best thing to do is get WinRAR working on its own using hand-made command-lines and file-list text files from a Command Prompt (i.e. Opus is not involvemed at all) and then once you have something that works, turn that into an Opus button.

Seems the useage of the @listfiles param is poorly documented by WinRAR. In all of the command line useage examples it SEEMS like you're supposed to be able to use @listfiles with ANY rar command... but as you've seen trying x or e for extracts seems to process the listfile incorrectly. BOGUS on WinRAR...

Anyhow... in the related 'Buttons and Toolbars' thread you posted in first, I think you mentioned that you liked how the WinRAR context menu handled the extract? If so... try creating a toolbar Menu that runs the following Opus function in a button under the menu:

Note!!! If you're doing this with a toolbar... you have to place a Menu item on the actual toolbar, and then add the function above to a Button under that menu... otherwise, the toolbar probably won't show the Context menu items provided by WinRar, since the list is instantiated based on what file types you've got selected, and the toolbar doesn't "refresh" AFTER you select RAR files subsequently to opening a lister... But a button 'under' the menu item will call the extension handler as you expand the menu while RAR files are selected...

By the way, your solution is quite good, but we came back to the same solution as the right click context menu, so I can't specify automatically an extract path.
For now, I prefer using @sync "C:\Program Files\WinRAR\WinRAR.exe" x f "E:\tmp\", because it does the job very well (just have the always on top Opus window ruining a bit the thing, but I'll survive).

Reply all
Reply to author
Forward
0 new messages