Bug 294013 - cannot delete file inside tar archive
Summary: cannot delete file inside tar archive
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Unclassified
Component: general (show other bugs)
Version: 2.0
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: investigated, regression, reproducible
Depends on:
Blocks:
 
Reported: 2012-02-13 19:09 UTC by Ivan D Vasin
Modified: 2013-06-22 12:05 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.11


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan D Vasin 2012-02-13 19:09:06 UTC
Version:           2.0 (using KDE 4.8.0) 
OS:                Linux

when navigating inside a tar archive, Dolphin provides an action to delete files inside it.  the action doesn't work, but both Dolphin and KNotify seem to think it does.

Reproducible: Always

Steps to Reproduce:
1. in Dolphin's settings, in the Navigation tab, enable "Open archives as folder".
2. navigate inside a tar archive.
3. delete a file in the archive.

Actual Results:  
* an info dialog is shown that says, "Could not delete file tar:/{path to tarball}/{path to file}."
* the file is not removed from the archive.
* KNotify shows a notification with the title "Deleting [Finished]" and the text "File: tar:/{path to tarball}/{path to file}."
* the file is removed from Dolphin's view of the archive.
* refreshing the view returns the file to it.

Expected Results:  
if deleting files inside archives is intended to be supported:
* the file is removed from the archive and from Dolphin's view of it.
* KNotify shows the message that it currently does.

if deleting files inside archives is not intended to be supported:
* at worst:
  * Dolphin shows the dialog it currently does, but as an error dialog instead of an info dialog.
  * the file is not removed from the archive.
  * KNotify indicates failure.
  * Dolphin's view retains the file.
* better:
  * Dolphin shows an error in its status bar.
  * the file is not removed from the archive.
  * KNotify indicates failure.
  * Dolphin's view retains the file.
* best:
  * delete is not available as an action on the file.

OS: Linux (x86_64) release 3.0.0-16-generic
Compiler: gcc
Comment 1 Frank Reininghaus 2012-02-21 22:40:45 UTC
Thanks for the bug report, I can reproduce the issue. Seems to be a regression - in earlier versions, the 'delete' action was greyed out (because it's really not intended that items can be removed from an archive inside Dolphin).
Comment 2 Peter Penz 2012-05-05 20:17:32 UTC
Hm, I cannot reproduce it with 4.8.3 + master.

@Frank: Would be great if you could also try it again in your environment with the recent versions to be sure. Thanks :-)
Comment 3 Frank Reininghaus 2012-05-06 09:40:59 UTC
I still can reproduce this in a 4.8 branch checkout (updated today), but not in master and neither in the 4.8.2 packages by openSuse. Strange.
Comment 4 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:19:51 UTC
Resetting assignee to default as per bug #305719
Comment 5 Jekyll Wu 2012-08-24 19:14:04 UTC
I just check this using KDE SC 4.9 .  The "Delete" action (now provided as a service) is grayed out when showing the context menu on some file within the archive. 

However, I notice another problem. If the delete service is disabled, the "Move to Trash" action is active in the context menu. It should be still grayed out.
Comment 6 Frank Reininghaus 2012-08-24 22:37:10 UTC
Thanks Jekyll for finding out this important detail! This pointed me to the piece of code which contains the bug.

It seems that this is due to the use of "m_removeAction" in DolphinContextMenu, an action which is used if "Show delete" is disabled. In DolphinContextMenu::updateRemoveAction(), the text, shortcut, etc. of this action is either set to "move to trash" or "delete" depending on if Shift is pressed or not. The missing piece is to set the "enabled" state of that action properly.
Comment 7 Frank Reininghaus 2012-08-25 07:54:00 UTC
Hm, just adding

m_removeAction->setEnabled(action->isEnabled());

in DolphinContextMenu::updateRemoveAction() indeed fixes the problem, but causes a new bug: When right-clicking a writable file for the first time, the "Move to trash" action is disabled, but it's enabled when opening the context menu again after that. It seems that the context menu is initialised before DolphinMainWindow::updateEditActions() had a chance to find out if the location is writable or not. Looks like I have to find a better solution.
Comment 8 Emmanuel Pescosta 2013-06-22 12:05:38 UTC
Git commit 4cd231838dc84b0fd17431374e9b1b42f55c2c4b by Emmanuel Pescosta.
Committed on 22/06/2013 at 12:04.
Pushed by emmanuelp into branch 'master'.

Update the "Move to Trash" action's and the "Delete" action's
enabled state in the context menu for read only files/folders (also
archives).
FIXED-IN: 4.11
REVIEW: 111160

M  +2    -1    dolphin/src/dolphinremoveaction.cpp
M  +6    -0    dolphin/src/views/dolphinview.cpp

http://commits.kde.org/kde-baseapps/4cd231838dc84b0fd17431374e9b1b42f55c2c4b