Somebody please correct me if I'm wrong, but this feature would probably destroy the zip file. The original information is not represented isomorphically through compression.
Well anyway, as viewing a zipped archive requires decompressing it anyway, write support should be achievable through a recompression. Now this would be slow. The casual user would feel very, very frustrated :)

Why would it destroy the zip file?

Windows XP has drag-and-drop in-filemanager writing to zip files. AFAIK it doesn't destroy the zip file! Maybe you mean it would destroy the zip file if done badly?

It doesn't require decompressing and recompressing. /usr/bin/zip can edit the zip file, removing and adding individual entries. So can ark, IIRC. What we need is for the kioslave to add this functionality.

The issue has nothing to do with "destroying zip files". Konqueror is a universal information viewer/browser if you will. As such it was originally designed to only allow you to view not modify content. This is evident from all the viewers that embed themselves into konqueror. Though most of them are capable of modifying the content they display, when embedded in konqueror they prevent you from doing any modification. The same applies to the zip:/, tar:/ other compressed content viewers. I even bet that if you opened the zipped archive in an embedded ark part you will not be able to add to it either. That is by design of konqueror and something that is not likely going to change anytime soon...

I'm glad we agree that 'destroying zip files' is a non-issue!

Can I offer the following further arguments?

- I have been using KDE since 1.0, and had never though of Konqueror as only a 'viewer'. Will people coming over from XP understand that Konqueror's only a viewer and therefore they shouldn't expect to be able to drag-and-drop into zip files any more?

- The following kioslaves are read-write: file, ftp, fish, floppy, mac, sftp, smb and maybe some others (nfs? imap? kamera?). Therefore I don't think it's true that Konqueror is just a viewer/reader.

- As it is, Konqueror is read-write almost all the time when used as a file-browser (see above list). This makes zip:/ a real anomaly, and unexpected behaviour.

- The logical outcome if Konqueror is only intended as a viewer/browser is that all the file creation/deletion/moving facilities should be stripped out!

- As it is, only the expert users will know how to write to zip files. This is because when you click on a zip file, it opens up in Konqueror via zip:/. Only an expert will know that they need to go to one of the menus and "open in ark". Hence writing to zip files is a feature hidden from normal users.

Hello,

I was not arguing the merit of being able to modify the content of archives. I was just simply explaining why konqueror behaves the way it currently does. It is a "ReadOnly" KPart not a "ReadWrite" one like say Kate. Personally I would love to be able to insert and remove files from archives.

You also seem to confuse io-slaves with embedded KParts and I am sure many others are confused by this as well. However, io-slaves are network transparent extenders for the filemanagement component of konqueror whereas embedded viewers are KParts (embedable parts) of other full fledged standalone apps or konqueror specific components. It is the latter ones that do not allow modification of content unless they are launched full fledged. Also technically being able to remove/create/add a file is not exactly the same as being able to edit/modify content. This is the whole filemanagement vs contentmangement debate. This is a distinction that was originally made when Konqueror was designed as a KPart for KDE 2.0 release...

Now to change this would mean to allow people to open any application in konqueror and use it as an editor and that of course would violate the original design criteria and require careful and I am sure a protracted rehashing and discussions of the merits of each approach. That is why I said it probably will "not happen anytime soon" in my previous response. Hope that clarifies things...

Dawit,

Thank you for taking the time to write this.

I don't want to see the KPart viewers (such as for KWord documents, images, 
etc.) become read-write. I think that would be confusing. I don't want to be 
able to "open any application fully fledged in Konqueror". I just want the 
filesystem view of zip files to come into line with that of floppy:/, fish:/ 
and file:/.

Let me try to explain what I'm getting at and justify why it wouldn't involve 
a change in Konqueror's design goals.

From a user's point of view, Konqueror appears to have two roles:

1) A file system browser (for local files, SMB, FTP, SFTP, Zip, etc.)

2) A read-only inline content-viewer (e.g. for PDFs, KSpread, KWord, images, 
text files, HTML, etc.)

In both cases the content may or may not have come over the network - it's 
network transparent. (Though of course there are still problems, e.g. 
chaining ioslaves - you can't get a filesystem view of a tar file if it's on 
a Samba share).

When Konqueror is viewing content (case 2), it's read-only. When it's 
providing a view of a filesystem (case 1), it's normally read-write (see the 
list in my previous comments). I'm arguing that consistency demands that it 
should be read-write when providing a filesystem view of zip files.

i.e. The ark KPart viewer should remain read-only; but the zip:/ kioslave 
should become read-write to bring it into line with smb:/, ftp:/, sftp:/, 
fish:/, etc. I don't think this is a fundamental change in the ideology of 
Konqueror. Rather, it's improving the consistency.

I think I grasp the difference between KParts and ioslaves, but it was helpful 
to have your explanation again. I am asking for the zip ioslave to become 
read-write. Presently to edit a file within a zip file you have to:
1) Unzip the whole .zip
2) Edit the file you're interested in
3) Zip it up again
It would be wonderful to be able to just edit and cut out the other steps!

Joe User is not going to understand why one filesystem view (zip:/) is 
read-only, whereas another (file:/, or smb:/) is read-write. He's just going 
to think that KDE is broken or lacks features ("Windows XP can do it!"). To 
be honest, despite your helpful explanation I do not see why it is that 
floppy:/ and file:/ can be read-write but to make zip:/ read-write would 
"violate the original design criteria" - what's the difference?

I suppose it could be argued that the difference is that editing a file within 
a .zip in fact edits the .zip file itself and amounts to making Konqueror an 
editor. At a technical level, yes that's true - but not at a conceptual 
level. Once the concept of a zip:/ ioslave (and not just an ark KPart) has 
been accepted - i.e. of presenting the .zip file as a filesystem - the bridge 
has been crossed. A .zip file is presently in Konqueror presented as a 
filesystem, not an individual file, in terms of how it is presented to the 
user. That is, when you click on a .zip it goes into a sub-directory view, 
rather than loading the ark KPart (of course you can load the ark KPart 
instead if you want to). Once we've decided to present it as a filesystem, 
there should be no reason for keeping it read-only - it doesn't violate 
Konqueror as viewer only for content, because this isn't content, it's a 
filesystem.

But you say you'd love to be able to insert and remove files, so maybe we 
agree - we just need to persuade someone to write the code! (I have no 
knowledge of C or C++ - otherwise I'd happily do it!)

*** This bug has been confirmed by popular vote. ***

*** Bug 76009 has been marked as a duplicate of this bug. ***

A related bug is http://bugs.kde.org/show_bug.cgi?id=115594. Here the point is to move or copy parts of OpenDocumement Format files between different ODF files, or extract parts of ODF-files to another part of the file system. Aside from the practical aspects of fixing errors created by buggy ODF aware applications, it would also be possible to show people the difference between an open format and a proprietary binary one. To make this happen, write support for the zip:/ protocol must be available.

any news for this old bug?

"Access denied. Cannot write to "zip:/some/path/and/file.zip""
So I guess it’s still valid :)

*** Bug 195760 has been marked as a duplicate of this bug. ***

Created attachment 126386 [details]
apparently outdated error message

it's still relevant. And the error message shown when I try to delete a file via context menu seems outdated. What is "Konfigurator"?

Operating System: Arch Linux 
KDE Plasma Version: 5.18.1
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1