Attempting to create a 7zip archive of either the ~/.mozilla or ~/.thunderbird folder results in a successful message popup ("Compressing 155 files (Finished)"), but the .7z file is never created. This message pops up immediately as well, which means file processing is actually performed. If you try to create the archive by manually launching Ark and clicking "Create New Archive...", when dragging either of the aforementioned folders into Ark, nothing happens. STEPS TO REPRODUCE 1. Make sure you have launched Firefox or Thunderbird at least once to create their configuration folders. 2. In Dolphin, right click either ~/.mozilla (for Firefox) or ~/.thunderbird (for Thunderbird) and select "Compress" -> "Compress to...". 3. When the compression window pops up, choose your preferred filename, select "7-zip archive" for the type and click OK. OBSERVED RESULT A popup says something like "Compressing 155 files (Finished)", but the .7z file is never created. EXPECTED RESULT The .7z file should be created. SOFTWARE/OS VERSIONS Linux: KDE neon 5.24 User Edition KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I can reproduce this bug in a KDE neon install within VirtualBox and also using fresh Thunderbird and/or Firefox profiles.
This bug is still present in Ark 24.02.2 (Plasma 6.0.4).
Initially I thought it could be a problem with names starting with a dot, but that's not the case, other directories are compressed okay. Starting with the vanity issue, even if the compression is stopped, the directory which should contain the resulting archive is opened which is unexpected. There's likely the lack of error handling here. As it could be seen that the external 7z tool is used to make the archive, caught the exact command used and ran it manually to see what's up. After a quite telling `ERROR:` line, the "offending" file is revealed: `stat error for .mozilla/firefox/Profile.ProfileName/lock (No such file or directory)` Looking at the file, `ls -la` shows the following: `lock -> 127.0.1.1:+2`. This is likely a good showcase of why 7z is recommended to be avoided for "non-trivial" archival purposes, as it has poor or no support for filesystem features not present or rarely used on Windows. Haven't verified, but as I've read once, it doesn't handle symbolic links, but just tries to add the files they are pointing to, and in this case the symbolic link is apparently being "abused" to contain program specific information instead of pointing at an existing file, so it's considered broken. Even if the symbolic link would point at an existing file, the archive would likely contain a copy of that file instead of the symbolic link, possibly making what should be a backup defective as you wouldn't get the exact same contents back when unpacking it. I'll set the CONFIRMED status, but there are some considerations here: - Part of the issue surely belongs here as error handling in Ark is apparently lacking, likely as a result of an external program being executed instead of everything being done in KIO as more typical - 7z not being Linux friendly is not really a KDE problem, although it's surely a UX issue. It's an interesting problem how failure should be handled as it may be considered okay in some cases. Seems like there was a temporary push towards official Linux support in the 7-Zip project, but doesn't seem like it got far: https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
*** Bug 419009 has been marked as a duplicate of this bug. ***
*** Bug 487758 has been marked as a duplicate of this bug. ***
Please note that the upcoming 24.05 ark release will have basic 7z support through libarchive, which fixes this issue (you just need to uninstall p7zip or disable the p7zip plugin from the ark settings). However, I won't close this report as the p7zip plugin is still the default one for the 7z format.
It seems Ark is totally silent about errors happening when using the 7z-modul. It's really dangerous for users trusting Ark to correctly with their data and it's also awful when wasting hours of compression work when the result can be anything up to not even creating a .7z-file. Xarchiver in comparison show the user a clear error message in a popup window which is how proper software should behave. So I think this bug should get the highest priority and be solved in code or at least by disabling the 7z-modul for compression by default. It's urgent! Greets!
It's me again already since I searched for the next bug I encountered and this bug came up as the result. I also ran into the compression failing after hours of 100% CPU usage and Xarchiver actually showed me the error message which was about too many levels of symbolic links in the source directory which actually made the target directory run out of space. 7-Zip actually has a command line switchs argument regarding symbolic links: -snl: store symbolic links as links If that means it doesn't follow symbolic links this problem would be solved by using that command line switch. Summary: Ark needs to show the user an option to toogle this!