Winrar Original

[Agnella Datson]

I have old data that I believe are old pictures or movies. I'm pretty sure I separated them with WinRAR playing around with it and just recently came upon the old files and was hoping to be able to check the files out, they might have some good memories in them if I can recompile them.

Typically, you simple make sure all of the parts of the multi-part archive are in the same directory, select the first one, and begin the extraction process either by double-clicking on it to open it with the utility, or by right-clicking and specifying the utility to open the archive with or the command to run against it.

If you are trying to take what are currently multiple parts of a multi-part archive and create a single larger archive because you no longer need to be concerned about the maximum file size, you must first decompress the archives, turning them into their original, decompressed form, and then you simply re-compress them into a single archive file, using whichever settings are appropriate to do this.

I would like to keep the original date when I extract all the files of a RAR file. As it is all the dates are changed to today's date. I'm using the most current version of Opus and Windows 11 pro.
Bob

I have a script that used to work and add multiple files to a Winrar archive, test the archive, then delete the original files. It worked great, then I broke it, and now cannot fix.problem now is that for each file I am adding to the archive, a new Winrar window pops up and tells me that a file is in use by another process.

First, you should use $file.fullname instead of $path\$file, for better practice. And second, use rar.exe not winrar.exe to archive via command line, because rar.exe is a console application, and it does not release the script to continue to the next file until this file would be added to the archive. Also it might be needed to use & before rar.

My situation: I create containter in VeraCrypt encrypted by AES-Twofish-Serpent with Whirpool. I put my data in here and then I split the container using WinRAR into smaller pieces without compression (for example 2 GB containter into 4 500 Mb files). I also set password for the RAR which is different from the password I set for the container.

To answer in a word, yes, it's less safe. But probably not for the reasons you are attempting to guard against. Everyone dealing with security can sometimes get sucked into the Fort Knox way of thinking, but this is not always the best way to go about security. Remember that security is a combination of many factors, two of the most prominent being safety, and usability.

Your method tends to lean towards the analogy of "can i guard my house by encasing the entire thing with concrete?" well yes, you can and it will be extremely difficult for anyone to get into your home. But if you're not careful, you yourself may end up without a way in.

Your method here adds an extra layer of security, but that layer is the password, nothing more. Splitting the file into 500mb entities serves to only apply a sort of "security through obscurity" approach, which would be cool if it were part of some scavenger hunt or hacker challenge, but for your own data not so much. Remember read write errors are a thing. The more you do this the more likely you are to miss a piece, or for something to go wrong when reconstructing the original encrypted container. Maybe it will be fine at first but over time you may find yourself unable to reconstruct it.

Secondly, what is the backup methodology here? are you going to create two or more of these? because if you do end up in a situation where you cant recover your files what then? If you want to be sure that a backup exists that will be there when you need it you may find yourself using another method. Then i have to ask, why wouldn't anyone who wants this data just go for that then?

This kind of thing almost always adds complexity for the user, and usually results in only marginal security gain. Since, veracrypt already has the option to create a hidden container within a container. This is considerably simpler and, i would wager, provides the same if not more security than what you propose here. Since in one case the enemy knows another password is required, and in the hidden container's case, they may not.

Given the current situation, your approach actually has the advantage that you can CRC-check the file's integrity when unpacking. If there is a problem, Winrar will tell you that (by the way, you should switch to 7Zip. It's better under every aspect).

I had developed backup methods that used deduplication to reduce the amount of drive space required for a full backup. I used two different deduplication methods, for two different backup sets. As detailed in other posts, one such method used Borg; the other used DoubleKiller.

Due to certain risks mentioned in those posts, I wanted to make a full, fail-safe backup without deduplication. This backup set would rely solely upon WinRAR compression to save drive space. In addition to good compression, WinRAR offered features that would be useful for this purpose, including encryption, the ability to split an archive into precisely sized pieces, a way of keeping backed-up files and folders organized within those pieces, and a hash value for integrity checking.

The splitting into pieces mattered because I wanted to burn this backup onto Blu-ray (BD-R) discs. Blu-ray had important backup advantages, including ransomware resistance and protection from some kinds of data loss. At 25GB per disc for the most economical choice, this approach would require time, expense, and volume for a stack of discs, and would thus be best used sparingly, not as the primary mode of backup. As discussed in a previous post, I would be using ImgBurn to burn the discs.

For this compression, encryption, and splitting task, I would be using largely the same WinRAR settings as in my Borg post. With those settings in place, I would select the drive or folders that I wanted to compress and back up onto BD-R, make sure I added a password in WinRAR, and then let it run. Over a period of hours (or days, for a really large fileset), WinRAR would churn away, producing those 24GB chunks for burning onto Blu-ray. This compressed WinRAR result required 14% less disk space than the uncompressed version of those files.

representing the BLAKE2sp hash, file size, and full path for a single file. I could leave the many lines of output in the output .txt file, or I could load them into a spreadsheet. Either way, I would plan to store copes of that list with the original files and on the Blu-ray discs. (Note also the hashing command efforts developed in other posts for Windows and Linux.)

A spreadsheet would be useful if I planned to take the optional step of comparing those hashes against the hashes produced by a different computer, running Linux. As discussed in another post, that precaution might detect that ransomware was stealthily running in Windows to corrupt data files in a way that the user would not detect. That possibility would come to light if the user found that Windows and Linux systems were computing different file hashes for the same file. My spreadsheet for this purpose generated one such Linux command for each file listed by the Windows command (above) (see discussion). The Linux commands generated by that spreadsheet looked like this:

That spreadsheet contained a facility for comparing the results of the Windows hashing against the Linux hashing. It could also compare two sets of Windows hashes. In the present case, that could mean a comparison of the original hashes against those produced by WinRAR or those generated at the end, by the same Windows command (above), after restoring files from Blu-ray and decompressing them using WinRAR.

I chose BLAKE2sp, as my preferred algorithm, in order to retain the option of checking hashes at another point in the process. In addition to the starting and ending hashes just mentioned, it could be worthwhile to use hashes calculated by WinRAR. It was not difficult to plug those hashes into the spreadsheet (above).

Another post details the process by which I obtained BLAKE2sp hashes from WinRAR. As that post indicates, I was able to obtain those hashes, and to get them into a spreadsheet-compatible form for comparison. The comparison largely confirmed that the files had survived the compression process intact.

My last step before burning to BD-R was to obtain hashes for the partXX.rar files. These hashes could be useful if, for instance, the BD-R discs encountered rough conditions. Before trying to extract thousands of individual files, it could be convenient to verify that the .rar files being restored from BD-R to disc were still in their original condition, as reflected in these hashes.

Once I had the hash list, I saved it onto the first or last BD-R in the series, along with any other hash lists and spreadsheets I wanted to preserve. If I wanted the names of files to be secured, I would have to encrypt those lists before burning.

A RAR file contains one or more files that have been compressed into a smaller file using WinRAR software. The .rar file extension name stands for Roshal Archive, meaning a high-quality compressed file (also known as an archive) that can be encrypted and password protected.

Acting as a container for compressed data, RAR files reduce the overall size of files being shared, facilitating quicker data transfers, and conserving storage space. Unlike some other data compression methods, because .rar files are fully compatible with encryption-enabled password protection, they're a popular format that balances efficiency with data security.

WinZip is a free app you can download from Google Play to open .rar formatted files on Android. But beware that while the app itself is free to download, it requires a paid subscription to use. However, it does come with a free trial option, so you can use it to extract RAR files you need right now, and then decide if you want to keep the premium version.

c80f0f1006