Franco Corbelli

After a bit of digging, and using -w/tmp/, I get this Error: cannot move the file /tmp/aserver_nooo.zip.tmp /monta/nexes_sei_aserver6/zip/aserver_nooo.zip Operation not permitted System ERROR: Unknown error: -2147024895

After switching from a Solaris-based NAS to a FreeBSD one, I get a strange beahyviour The NFS share is mounted as /monta/nexes_sei_aserver6 It is writeable root@aserver:/monta/nexes_sei_aserver6/zip # echo "ciao" >prova.txt root@aserver:/monta/nexes_sei_aserver6/zip # cat prova.txt ciao There is a squash-to-user utente When I try to write on a .zip file, like this root@aserver:/monta/nexes_sei_aserver6/zip # /usr/local/bin/7z a -tzip -mx1 /monta/nexes_sei_aserver6/zip/prova /etc 7-Zip [64] 16.02...

BTW: thoroughly testing the restorability of an archive is very different from simply testing it. It presupposes writing to a real filesystem (to check the charset and length, for example) and then comparing file hashes', or whatever. 7-zip is a (very good) archiver, not a backup program, nor do I think it wants to be. For a paranoid++ level you use a different operating system, a different filesystem, a different CPU, and a different compiler (!) and a 3rd-party software to double check (!!). But,...

Indeed, corrupted archives can happen, even for subtle bugs, for individual configuration (e.g., the terrifying fake Windows Server files, rather than the "fake video game files" of desktop versions), hardware errors etc. I personally get one such a "strange" case ...where... I threw in the towel. I have not been able to figure out why. In my specific case I adopt paranoid++ level verification strategies, but I am aware that for those who do not do my job they are essentially excessive. The very...

Here writing a 100GB container file (just to get an idea) @ 2.2GB/s on NVMe, by VeraCrypt I also tried to disable multithreading, for some kind of hypothetical race condition (the CPU has 32 logical cores), with no effect On the CPU-side the slowest (Kuznyechik(Serpent(Camellia)) runs at about 1.3GB/s AES 29GB/s, Twofish 5.9GB/s (50MB blocks) Does not seems a CPU related issue

Here the "plain" drive

In the attached images - NON encrypted write speed (from ramdisk) is ~2.2GB/s - VeraCrypt encrypted, after the "cache spike", goes to ~70MB/s - VeraCrypt, during the encryption process, writes at ~2GB/s Short version: on SSD 500MB/s, on NVMe 70MB/s, very same PC, testbed etc It is rather strange

Thanks for the answer I am a very seasoned disk encryption user (10+ years) I do not use antivirus of any kind, etc. No Defender at all I have numerous other machines with TrueCrypt, on which the problem recurs in the same way (SSD, HDD OK, NVMe KO), different CPU (Intel/AMD), different chipset, different "everything". I have read numerous reports of poor performance on NVMe with VeraCrypt, so I suppose it is a really existing problem Precisely in order to exclude any kind of hypothetical software...