Bug 171800 - Attachments dragged to desktop have read-only permissions
Summary: Attachments dragged to desktop have read-only permissions
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords: triaged
: 185837 208986 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-09-28 16:53 UTC by Jonathan Thomas
Modified: 2012-07-03 12:20 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Thomas 2008-09-28 16:53:37 UTC
Version:           1.10.1 (using 4.1.2 (KDE 4.1.2), Kubuntu packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.26-5-generic

This is similar to bug 79685, in the sense that both deal with attachments getting read-only rights. The difference is that this occurs when attachments are dragged to the desktop, and the disregardUmask=ture option doesn't work. Saving the attachments work as expected.
Comment 1 Ruchir Brahmbhatt 2009-04-12 10:59:26 UTC
Reproducible on 1.11.2. When we drag & drop attachment anywhere not just desktop, it has only read permissions but when we save as, it has write permission as well.
Comment 2 Jaime Torres 2009-06-10 16:07:22 UTC
I guess the problem is not totally kmail fault:
  kmail drags a Url list, and when dolphin or plasma drops it, they create read-only files.

  If kmail uses the right mime type for each attachment, there is another problem:
* In plasma, it will try to open the plasmoid to handle the type. For example, an image will open the preview plasmoid. But dows not allow to create a file.
* In dolphin, an image mime type is not allowed to drop.

  You can check it trying to drag&drop the image captured with ksnapshot.
Comment 3 gerlos 2009-06-11 16:55:32 UTC
(In reply to comment #1)
> Reproducible on 1.11.2. When we drag & drop attachment anywhere not just
> desktop, it has only read permissions but when we save as, it has write
> permission as well.

The same on kmail 1.11.4. When I drag & drop any attachment (I've tried also with png images) from kmail windows to any file manager window, that file will be saved in read-only mode.

When I save using the right click menu and "save as" instead permissions are fine.
Please correct this, it would be really comfortable if we could just drag attachments out of the windows to save them.
Comment 4 Christophe Marin 2009-08-17 16:30:41 UTC
*** Bug 185837 has been marked as a duplicate of this bug. ***
Comment 5 Martin Koller 2009-08-30 14:55:25 UTC
As this is a problem with the drop-target application, I reassign to dolphin.
Comment 6 Jaime Torres 2009-09-30 15:51:58 UTC
*** Bug 208986 has been marked as a duplicate of this bug. ***
Comment 7 davidblunkett 2010-08-14 10:41:04 UTC
I get this in 4.4.2 - this has been with us since 3.5 and is really annoying
Comment 8 Christophe Marin 2010-08-14 10:41:58 UTC
*** Bug 164997 has been marked as a duplicate of this bug. ***
Comment 9 Peter Penz 2010-09-02 20:29:14 UTC
I don't know why this has been assigned to Dolphin - Dolphin is not involved when dragging between kmail and the desktop -> reassigned to plasma
Comment 10 Björn Ruberg 2010-09-11 01:13:01 UTC
@ Jaime Torres:
But kmail does save the attachments as read-only temporary files? In that case, either plasma and dolphin may just copy the read-only property.
Comment 11 Aaron J. Seigo 2010-09-28 03:45:34 UTC
yes, it's simply copying the permissions already there. perhaps kmail should set the permissions to whatever it uses by default for "save as" before starting a drag (and resetting it afterwards). a bit of a hack, perhaps, but i don't see how else we could work around this issue without changing the permissions of all files that are copied into folderview (which would, imho, be a bug in the general case).
Comment 12 Laurent Montel 2012-07-03 12:20:47 UTC
I fixed it in 4.9