[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    [Bug 73969] New: attachment viewer - temp file writable
From:       Guido Draheim <guidod-2003- () gmx ! de>
Date:       2004-02-01 18:33:02
Message-ID: 20040201183302.24926.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
      
http://bugs.kde.org/show_bug.cgi?id=73969      
           Summary: attachment viewer - temp file writable
           Product: kmail
           Version: 1.5.3
          Platform: Mandrake RPMs
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: kmail-devel@kde.org
        ReportedBy: guidod-2003-@gmx.de


Version:           1.5.3 (using KDE KDE 3.1.3)
Installed from:    Mandrake RPMs
OS:          Linux

Here we have a typical `new user` problem - the user goes to "open" 
an email attachment (.doc in this case) and the appropriate viewer 
opens with it (openoffice in this case) where the attachment viewer 
is given a temp file as an argument.

Now the user starts to edit (!!) the viewed document - and clicks
on "save" in the attachment viewer (openoffice in this case). The
save succeeds, to the temp file (!!), which is right away removed 
when exiting the attachment viewer. (oops).

The user said she was expecting the attachment in the mail (!!) to 
be modified after the save operation. That is not the case, of course.
Effectivly, all changes are "lost" which makes her very unhappy. :-(

how to fix:
the attachment viewer application should be signaled in some way that
the temp file is not actually writable. A "save" operation would then
result in triggering a "save as" routine. That would atleast make
changes not to be "lost" completely.

The actual implementation of such a no-write attribution offers some
variants - easiest might be to chmod readonly the tempfile. Perhaps
that needs some other facilities within kmail to know they can still
be deleted. (btw, some very old operating system had once a file 
attribute "deletable" that could be set seperately from a "writeable"
flag). That implementation would be rather straightforward.

The other solution I can think of, is about getting it right with
edit/view associations and special options on the viewer fork/exec.
I expect that to get broken however over and over again. So it might
be best to make over the temp file handling of viewed attachments.
(and perhaps generalize it to the whole desktop as it is in some way
related to object linking and embedding behavior).

have fun, guido & mark               http://google.de/search?q=guidod
_______________________________________________
KMail developers mailing list
KMail-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]