Did you probably select another message while OpenOffice was still starting up?

No, I select only one message without a (before) started OpenOffice!
It's strange, isn't it?

*** This bug has been marked as a duplicate of 39537 ***

KDE-PIM bug weekend:  Still reported as a problem, but only in certain cases.
(openoffice works for some, gimp doesn't).  Reopening for further investigation.

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

As per bug 138102, here's an analysis:

kmail calls amarok, which (almost immediately) returns, having run some subprocess, or whatever. KMail/KIO says "oh, the app's done" and removes the file from /tmp, so amarok can't open it.

For an easy example, try opening an mp3 with the following shell script:
#!/bin/sh
nohup mpg123 $1 &
exit

It will fail :-). If you remove the 'nohup' and the '&' it works fine.

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

KMail opens the attachment using KRun::run(), with the tempFiles option set to true.  That eventually runs kioexec in a subprocess with the --tempfiles option, which runs the real application in another subprocess to open the file.  When that application finishes and returns to kioexec, the temporary file is deleted.

Unfortunately, if the application forks and the parent process exits immediately, as desktop applications often do, kioexec will delete the file before the forked application has had the chance to read it.

One solution would be to modify kioexec to not delete the temporary file immediately - wait for a reasonable time so that even if the application does fork it will have time to start up and read the file before it gets deleted:

--- kdelibs-3.5svn/kio/kioexec/main.cpp (revision 607803)
+++ kdelibs-3.5svn/kio/kioexec/main.cpp (working copy)
@@ -260,6 +260,10 @@ void KIOExec::slotRunApp()
             if (!tempfiles && dest.isLocalFile())
                 continue;
         }
+
+       kdDebug() << "sleeping..." << endl;
+       sleep(120);
+       kdDebug() << "about to delete " << QFile::encodeName(src) << endl;
         unlink( QFile::encodeName(src) );
     }

Doing this fixes the attachment opening problem (unless the application takes more than 2 minutes to start up :-)  However, I don't know whether there will be implications for any other users of kioexec or KRun.

Should this bug be reassigned to kdelibs/kio?

Yes, it should be reassigned :-)

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

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

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

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

After error message, if I try to open the attachment a second time, it works.

see also
http://bugs.kde.org/show_bug.cgi?id=140953
which might be a different imap related thing

Elmar, what kind of WORKSFORME is this? "After an error"? Yeah, not counting errors there are hardly any bugs in software.

I get the errormessage that the file do not exist in /tmp -folder.

I am aware of that. But you set the status to worksforme, because when you try the second time it works. It is a workaround of the bug, this does not resolve the problem.

And it may or may not worksforme, due to timing issues - if the application is already in memory the second time, it will respond faster and possibly open the temporary file in time.  So leaving the bug open until it gets resolved.

See also bug 94336, possible duplicate

Bug 94336 is also the same root cause, but with an added complication.

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

Amarok needs to implement --tempfile so that it says "I handle the deletion of the tempfile myself". With X-KDE-HasTempFileOption=true in its .desktop file, it can indicate that it supports the option, and then kmail/kioexec won't delete the file, amarok will. This is necessary in all kde applications which have a helper binary that talks to the running program - like amarok/amarokapp and kfmclient/konqueror.

For OpenOffice (when it's already running), I don't know a good solution. I guess we need a last-resort option, basically a "delete this temp file in a very long time (or never)" (in kio) for those apps which cannot implement proper handling of tempfiles.

IMHO it is necessary for all (?) applications to handle "remote" files the way described in 
http://bugs.kde.org/show_bug.cgi?id=130709#c23

to achieve the network transparency wich KDE is claiming to provide.

How can this be checked / implemented ?

All KDE applications support remote files via KIO, that's not the problem here.
The problem is temporary files (they are local, not remote, and they need to be deleted), and temporary files are only a problem for applications that "talk to a running instance" (like kfmclient, amarok and openoffice.org). No problem for kedit, for instance: you open kedit on the temp file, and whenever kedit is closed, kioexec deletes the tempfile.

David, does your explanation in
http://bugs.kde.org/show_bug.cgi?id=130709#c25
explains 
http://bugs.kde.org/show_bug.cgi?id=140953#c2 ?

No, online imap and loading attachments on demand or not, is probably another problem.
Of which I have no clue about; I use (and wrote parts of) cached imap, but not online imap.
Probably another code path that deals with tempfiles.

Reassigning to amarok, see comment #23.

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

Assigning back to KMail. The original problem is with OpenOffice, and it seems not solved yet.

Anyone having the same problem with Amarok should open a new bug report there if none exists yet.

This problem exists with OpenOffice as well, or at least this problem is exhibited when the ooffice quickstart applet is running.  Is it really the right approach to expect all of the applications that exhibit the same problem (kaffeine, openoffice quickstart, amarok, etc.) to have to deal with this problem?  Shouldn't this be addressed in the kde code that deals with tempfile creation/destruction?  Is it possible for that code to create the tempfile, sleep X amount of time, and then loop looking for still-open filehandles in the OS before unlink()ing the tempfile?

This bug is getting thrown back and forth between various owners, with no resolution in sight yet.  Could at least the fix (=hack, acknowledged) in comment#8 be accepted into kdelibs - this would fix the problem in the common cases with the most popular applications, and avoid the duplicate bug reports.

SVN commit 652915 by dfaure:

forwardport 652914:
OK, we can wait 3mn before deleting a tempfile, if it helps with apps that fork on startup like OOo or amarok.
Thanks to Jonathan Marten for the idea and patch.
BUG: 130709


 M  +9 -2      main.cpp  


--- trunk/KDE/kdebase/runtime/kioexec/main.cpp #652914:652915
@@ -240,9 +240,16 @@
             }
         }
 
-        // don't delete a local file, except it is defined to be temporary (with --tempfiles switch)
-        if ( !dest.isLocalFile() || tempfiles )
+        if ( !dest.isLocalFile() ) {
             unlink( QFile::encodeName(src) );
+        } else if ( tempfiles ) {
+            // Wait for a reasonable time so that even if the application forks on startup (like OOo or amarok)
+            // i will have time to start up and read the file before it gets deleted. #130709.
+            kdDebug() << "sleeping..." << endl;
+            sleep(180); // 3 mn
+            kdDebug() << "about to delete " << src << endl;
+            unlink( QFile::encodeName(src) );
+        }
     }
 
     QApplication::exit(0);

Thanks David!!  =:)

Please could someone cross check -

opening documents (excel , oasis) with OO from sftp connections does not work any more - 
If OO is not runnning - I get the splash screen, but OO exists immediatly afterwards.
If OO is running - it exists immediately.

kspread works, gnumeric asks for password and opens.

cu

On Thursday 12 April 2007, Ferdinand Gassauer wrote:
> opening documents (excel , oasis) with OO from sftp connections does not work any more - 
> If OO is not runnning - I get the splash screen, but OO exists immediatly afterwards.
> If OO is running - it exists immediately.

Ah, right. Remote documents in non-kde apps need the same treatment as temp files from e.g. kmail.
I'll adjust the fix.

SVN commit 653071 by dfaure:

Wait before deleting the tempfile in the "tempfile due to opening a remote file" case too, of course.
CCBUG: 130709


 M  +2 -4      main.cpp  


--- branches/KDE/3.5/kdelibs/kio/kioexec/main.cpp #653070:653071
@@ -255,11 +255,9 @@
             }
         }
 
-        if ( !dest.isLocalFile() ) {
-            unlink( QFile::encodeName(src) );
-        } else if ( tempfiles ) {
+        if ( !dest.isLocalFile() || tempfiles ) {
             // Wait for a reasonable time so that even if the application forks on startup (like OOo or amarok)
-            // i will have time to start up and read the file before it gets deleted. #130709.
+            // it will have time to start up and read the file before it gets deleted. #130709.
             kdDebug() << "sleeping..." << endl;
             sleep(180); // 3 mn
             kdDebug() << "about to delete " << src << endl;

Hi David!
the patch  #37 didn't help

trying to open a sftp-xls I get this


konqueror: KonqMainWindow::openView ok=false bOthersFollowed=false returning false
konqueror: emit m_extension->openURLRequest( sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls,application/msexcel)
konqueror: KonqMainWindow::slotOpenURLRequest frameName=
konqueror: KonqMainWindow::openURL (from slotOpenURLRequest) url=sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls
konqueror: KonqMainWindow::openURL : url = 'sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls'  serviceType='application/msexcel req=[]' view=0xb0aa70
konqueror: trying openView for sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls (serviceType application/msexcel)
kio (KTrader): KServiceTypeProfile::offers serviceType=application/msexcel genericServiceType=Application
konqueror: KonqMainWindow::openView application/msexcel sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls 0xb0aa70 req:[]
konqueror: KonqMainWindow::openView application/msexcel sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls 0xa7a840 req:[followMode]
konqueror: KonqView::openURL url=sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls locationBarURL=sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls
konqtree: KonqDirTree::followURL: sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls
konqtree: KonqDirTree::followURL: Not found
libkonq: ## addToHistory: sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls Typed URL: sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls, Title:
konqueror: KonqMainWindow::openView ok=true bOthersFollowed=false returning true
libkonq: No X-KDE-AutoEmbed, looking for group
libkonq: KonqFMSettings::shouldEmbed : serviceTypeGroup=application
konqueror: openView: KonqFMSettings says: don't embed this servicetype
konqueror: KonqMainWindow::openView ok=false bOthersFollowed=false returning false

does it help - or is it a different thing.

On Thursday 12 April 2007, Ferdinand Gassauer wrote:
> konqueror: KonqMainWindow::openView ok=false bOthersFollowed=false returning false


The question is what happens after that.
And can you see a kioexec process (e.g. in ksysguard) after clicking on the file?

the command
kioexec oocalc sftp://gass@sw-ssh:22001/daten/dos/private/gass/kg_stat.xls
works
so it must be elsewhere - I'll recompile kdelibs and kdebase

Att: David!

Is I said before kioexec works fine if called from the command line, both if OO is open or not and writes back the changes to the sftp directory after closing all instances of OO. IMHO to late as many/most users will keep OO open for the working day. We have discussed this matter already many,many month ago.

Could it be that konqueror calls kioexec for sftp files with --tempfiles switch?

kioexec --tempfiles swriter sftp://gass@sw-ssh:22001/daten/dos/private/gass/ASP-offen1.doc

I get this:
 
Remote URL
sftp://gass@sw-ssh:22001/daten/dos/private/gass/ASP-offen1.doc
not allowed with --tempfiles switch

and kioexec exits. 

BTW: I do not get the errormessage with konqueror

Hi. i'm linking this bug to bug #70981 reported in Ubuntu

https://bugs.launchpad.net/kdepim/+bug/70981

I hope this can be addressed soon.

Thanks a lot for your help

please note that the bug # provided before (C42) corresponds to the associated bug report in Ubuntu's Launchpad.

Thanks

I would like to note, that not only OO attachments fail, but often others like kview, acroreader et al also exhibit the same behavior.  The one thing that is referenced in the comments, but doesn't seem to be fully explained is why the naming convention mismatch, ie the tmp files are in the tmp directory, but with a different name, (ie without the _(random_chars) inserted in the file name.

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

KDE 3.5.7 with OOWriter -- still does not work. Even if I load OOWriter in advance still, the attached doc is not opened.

Is the status FIXED really applies here?

works here with kubuntu (Feisty) and KDE 3.5.7 with .doc and .odt

Comment #46: WORKSFORME here with oowriter and any supported type of attachment.  Note that oowriter does not fork the application, so the race condition for deleting the temporary file should not apply here anyway.

Could you attach the results of:

grep kioexec ~/.xsession-errors

(or whatever log file receives the KDE debug output)?

Hmm, I tuned it a bit and it works, but I am not sure where the sub-bug lies.

Jonathan (#48 comment) grep shows nothing, I didn't switch KDE debug output (I believe), so if it is the default one, there is no info here.

I tested KDE 3.5.7 + OO 2.1, it failed. Then I tested with OO 2.2. It also failed, but I noticed that KMail asks about OO Writer 2.1. I went to file association, move OO Writer up (the order was OOW 2.1, OOW, OOW2.0 ???, KWord). Apply. I tested, it finally works.

Was it a problem with packaging of OO, that it didn't register correctly?

For what it's worth:

You can easily workaround this bug by creating a wrapper script sleeping a while before returning:

  chris@nisroc:~/bin$ cat ooffice-delay
  #!/bin/bash
  ooffice "$@"
  sleep 180

If you start opening your office documents using this wrapper you will be able to open all documents as expected.

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

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

I don't believe that comment #50 is a valid solution for this bug.  Why an user must create a script to open an office file, if he always opens such a file directly wiht openoffice???

this won't help linux on the desktop at all..

Please consider your users

Thanks a lot!!

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

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

What i can confirm:

Clickin on an ODS file in konqueror:sftp/fish does not work. I get the OpenOffice splash screen, but OO exists immediatly afterwards.

Konqueror 3.5.9
KDE 3.5.10
OpenOffice 2.4.1
Debian Lenny/stable

Did anyone experience this bug with KDE 4?

(In reply to comment #57)
> Did anyone experience this bug with KDE 4?

Not here.

no