warfall - 2014-01-21

Hello to everybody, excepted the one that have removed my previous post on the same topic (*)

Description of the context of the problem:

1/ usage of numerous 'virtual machines', this is ending with very larges files (between 30Gb and 200Gb) once compressed / encrypted for archiving. Typically, 7Zip have to manage more than 100Gb of files daily.

2/ usage of a SSD for system drive. This SSD not belonging to the 'pro' category, it have only 40Gb of writes per day for five years guaranteed by the maker. Obviously, none of those 'virtual machines' neither their archived / 7Zipped versions are located on the SSD, they stand on more conventional HDDs.

3/ systematic usage of "tar | 7z" (tar files to preserve permissions, then pipe result for compressing / encrypting by 7Zip) to compress the Linux / Unix 'virtual machines'.

4/ verification of the archives before sending them to backup devices.

Description of the problem itself:

1/ when opening with graphical interface of 7Zip, under Windows 8.x / 2008R2 / 2012R2 operating systems, the compressed Linux / AIX 'virtual machines' (so a 'tar' file then 7zipped), the temporary 'tar' file is logically located to the standard working folder of 7Zip (whatever release of 7Zip): %userprofile%\AppData\Local\Temp\7zO... ( "..." being random numbers ). %userprofile% being located, this is standard for Windows, on the system drive, here the SSD drive.

2/ the volume (30Gb to 200Gb) of the 'tar' file being too high for the SSD regarding a daily usage, i have tried to use the "temporary folder" option of 7Zip graphical interface, while also de-activating the "only for removable media" option of 7Zip graphical interface.

3/ and here is eventually the problem: even with those 7Zip options set to be located on a conventional HDD, when opening an archive 7Z file, 7Zip continues to extract the 'tar' file to its standard working directory on the SSD system drive: %userprofile%\AppData\Local\Temp\7zO... ( "..." still being random numbers ).

I'm aware that some other solutions might be available:

a/ not using "tar | 7z" for archiving Linux / Unix 'virtual machines'. But 'tar' is too much good for rendering this solution acceptable.

b/ locating %userprofile% outside the system drive. This will render some other programs (other than 7Zip itself) tricky to manage under Windows, while being a 100% working solution.

c/ usage of a professional grade SSD, ending to something far over 40Gb of writes allowed per day. A very, very expensive solution, not well related with the usage of the free 7Zip anyway, while being a 100% working solution.

Eventually, here is my request for enhancement:

It is obvious that in some specific conditions (even if i think that at least one virtual machine, easily ending with a size somewhere between 30 to 60Gb, will be very standard in 2 to 3 years for half the systems existing), 7Zip is currently not compatible with the usage of a consumer grade SSD, regarding the lifespan of the SSD.

While other solutions may exist, i think reasonable to ask for an enhancement of 7Zip: making it writing every temporary files, even the one used for read operations, on the location specified by the already existing 7Zip option "temporary files folder location".

While my previous post had been removed without any valid reason, i don't change my sum up:

I'm an happy user of 7Zip since more than 15 years for various reasons: the price, free is nice; the reliability, never had a single problem with 7Zip, also previous 4.x version files still being readable / extractable by 9.x version; the support of various platforms, 7Zip format is very useful to exchange files between Windows and Linux / Unix, even some Z/OS; and the encryption option, i rely on 7Zip encryption for privacy.

All of this can only lead to say thank you Igor Pavlov.

And without withdrawing any of those words, i must observe that today, for the first time since 15 years, my only solution is currently to look for another archive manager program (i'm speaking about the program, 7Zip format itself not being planned to be replaced (**)).

(*) regarding this point, i have strong hopes this is not Igor Pavlov himself. Anyway, without clarification on that removal this is putting some dark and very unfortunate light on 7Zip project itself, and if the same thing happen one more time: removing an honest report of a drawback of the 7Zip program (who cares anyway? is that the first program with drawback?), some more formal steps will be proceeded.

(**) 7Zip format itself not being planned to be replaced? Well, this was undoubtedly my position before the inexplicable removal of my previous post, but i must say that from now on this point can't stand anymore the strong affirmation which yet seemed obvious to me an hour ago.