| Summary: | Creating archives from files without a common name prefixes are just named "archive" instead of the folder name. | ||
|---|---|---|---|
| Product: | [Applications] ark | Reporter: | Natalie Clarius <natalie_clarius> |
| Component: | general | Assignee: | Elvis Angelaccio <elvis.angelaccio> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | aacid, fkfd, meven29, natalie_clarius, rthomsen6 |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Natalie Clarius
2022-03-06 17:39:01 UTC
There was no consensus or majority apparent for users who expressed their opinions in their votes. In fact most users who voted in the discussion seem to see the new behavior as good, but this was no proper poll. > Throwing completely unrelated files together and giving it a name about something entirely different would be a very strange way of using folders, and not something most normal users do We cannot make assumptions on how users are disciplined in creating semantically relevant folders and storing only files relating to that. That's the error previous behavior did. How about the Downloads folder ? How about a Videos dirs containing subtitles ? A document directory containing photos ? > Zipping a bunch of files from different subdirectories of a common grandparent directory, then moving or uploading them together to a common place, is something rather common for me to do. Having 12 files just labeled "archive.zip", possibly auto-renamed because the file names will conflict, with no way to tell which is which, is going to be really annoying. I don't understand the workflow exactly. It seems this can be achieved using a few rename F2 or using ark. The change made this workflow less convenient for sure. But we can't base behaviors on one user particular workflow. On the other how many users confusion will be alleviated by the change ? Relevant MR https://invent.kde.org/utilities/ark/-/merge_requests/101 (In reply to Méven Car from comment #1) > There was no consensus or majority apparent for users who expressed their > opinions in their votes. > In fact most users who voted in the discussion seem to see the new behavior > as good, but this was no proper poll. Looks like we're seeing different votes counts then. But yes, it is not very representative of course. > We cannot make assumptions on how users are disciplined in creating > semantically relevant folders and storing only files relating to that. I don't follow along with how making the assumption that users are undisciplined is warranted then. > How about the Downloads folder ? > How about a Videos dirs containing subtitles ? > A document directory containing photos ? I would think that in all those cases, if that's where users find their original files then that's what most effectively indicates where the archive is coming from; more effective than "archive" at least. I don't think that someone who isn't confused by putting their subtitles in a video folder would be confused by an archive of the same name containing these files, or to have an archive consisting of downloaded files to be named "Downloads.zip". But of course I can only answer your questions from my own perspective. > I don't understand the workflow exactly. > It seems this can be achieved using a few rename F2 or using ark. > The change made this workflow less convenient for sure. > But we can't base behaviors on one user particular workflow. Sure. Hence this issue, to officially indicate interest and have a place for people to voice their opinion. If it turns out that noone supports a revert to the old behavior, then that's a valid outcome. > Relevant MR https://invent.kde.org/utilities/ark/-/merge_requests/101 Thanks. I think the preceding discussion addresses all arguments made there. So I was compressing some files today, and I noticed something I thought was a bug but is actually related to this thread. Versions: Ark 22.04.3, Dolphin 22.04.3, Plasma 5.25.3, KF 5.96.0, Qt 5.15.5 on Arch Linux, kernel 5.18.14 Steps to reproduce: 1. Create two files named "abcde.c" and "abcde.h" in dolphin 2. Select both, then right click 3. Hover on "Compress" Expected behavior: context menu provides sensible filenames like "abcde.tar.gz" Observed behavior: the filenames are "abcde..tar.gz" and "abcde..zip" (two dots) I read the source code and it should be related to the algorithm to find common prefixes (https://invent.kde.org/utilities/ark/-/blob/master/kerfuffle/addtoarchive.cpp#L205). If the last common character is '.', it will precede another '.' and make the filename appear weird to anyone who hasn't seen the code. I think we should fix it as a special case. If it sounds good to you I'll begin writing a patch soon. (In reply to Frederick Yin from comment #3) > So I was compressing some files today, and I noticed something I thought was > a bug but is actually related to this thread. > > Versions: Ark 22.04.3, Dolphin 22.04.3, Plasma 5.25.3, KF 5.96.0, Qt 5.15.5 > on Arch Linux, kernel 5.18.14 > > Steps to reproduce: > 1. Create two files named "abcde.c" and "abcde.h" in dolphin > 2. Select both, then right click > 3. Hover on "Compress" > Expected behavior: context menu provides sensible filenames like > "abcde.tar.gz" > Observed behavior: the filenames are "abcde..tar.gz" and "abcde..zip" (two > dots) Prefer reporting another bug next time ;-) This is a completely different issue. Bugs report are not conversations, they aim to gather information to resolve the bug, or discuss the resolution. > > I read the source code and it should be related to the algorithm to find > common prefixes > (https://invent.kde.org/utilities/ark/-/blob/master/kerfuffle/addtoarchive. > cpp#L205). If the last common character is '.', it will precede another '.' > and make the filename appear weird to anyone who hasn't seen the code. I > think we should fix it as a special case. > > If it sounds good to you I'll begin writing a patch soon. You got it right, patch welcome. I would special case, this line to avoid appending '.' when base already ends with '.' : https://invent.kde.org/utilities/ark/-/blob/master/kerfuffle/addtoarchive.cpp#L254 (In reply to Méven Car from comment #4) > (In reply to Frederick Yin from comment #3) > > So I was compressing some files today, and I noticed something I thought was > > a bug but is actually related to this thread. > > > > Versions: Ark 22.04.3, Dolphin 22.04.3, Plasma 5.25.3, KF 5.96.0, Qt 5.15.5 > > on Arch Linux, kernel 5.18.14 > > > > Steps to reproduce: > > 1. Create two files named "abcde.c" and "abcde.h" in dolphin > > 2. Select both, then right click > > 3. Hover on "Compress" > > Expected behavior: context menu provides sensible filenames like > > "abcde.tar.gz" > > Observed behavior: the filenames are "abcde..tar.gz" and "abcde..zip" (two > > dots) > > Prefer reporting another bug next time ;-) This is a completely different > issue. > Bugs report are not conversations, they aim to gather information to resolve > the bug, or discuss the resolution. Sorry for bringing this one off-topic. I went ahead to file another bug request later (#457269), *but* it turns out someone thought of this ahead of me and sparked a discussion involving the randomness of user behavior (invent MR !120, https://invent.kde.org/utilities/ark/-/merge_requests/120). > > > > I read the source code and it should be related to the algorithm to find > > common prefixes > > (https://invent.kde.org/utilities/ark/-/blob/master/kerfuffle/addtoarchive. > > cpp#L205). If the last common character is '.', it will precede another '.' > > and make the filename appear weird to anyone who hasn't seen the code. I > > think we should fix it as a special case. > > > > If it sounds good to you I'll begin writing a patch soon. > > You got it right, patch welcome. > I would special case, this line to avoid appending '.' when base already > ends with '.' : > https://invent.kde.org/utilities/ark/-/blob/master/kerfuffle/addtoarchive. > cpp#L254 I wrote a patch locally and got it working, but I would abstain from pushing just yet and observe how the MR goes. Thanks for your support! |