https://bugs.kde.org/show_bug.cgi?id=453452
Pedro V <voidpointertonull+bugskde...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
CC| |voidpointertonull+bugskdeor
| |g...@gmail.com
--- Comment #2 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
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/
--
You are receiving this mail because:
You are watching all bug changes.
