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

List:       kde-bugs-dist
Subject:    [Bug 150699] KPDF unable to save opened but deleted document
From:       Pino Toscano <pino () kde ! org>
Date:       2008-08-20 15:23:56
Message-ID: 20080820152356.18ED37B60 () immanuel ! kde ! org
[Download RAW message or body]

http://bugs.kde.org/show_bug.cgi?id=150699





--- Comment #5 from Pino Toscano <pino kde org>  2008-08-20 17:23:53 ---
(In reply to comment #4)
> I beg to differ. Of course, the original report of bug 114485 misses a complete
> explanation, so we cannot be sure, but the symptoms are clear.

Same symptoms could be originated from different causes, so just forget that
bug (like the original reporter seems to have done) and concentrate on this
one, ok?

> Let me restate a reproducible case, [...]

... as already documented in okular's bug 163363.

> Now, whether this is a kpdf problem or a Firefox problem. From a user's point
> of view, it is definitely a kpdf problem.

Especially when firefox removes the downloaded files, it happens with any
application out there that is started that way.

> As mentioned, for example acroread manages to save a file it "currently has
> open". Apparently they must keep the file cached somewhere or use other magic
> to achieve what they do.

They can do that as they have no "watch file" function, I suppose.

So, if you choose to watch your documents for changes, keeping the file open
breaks this feature (and I think that the users of that would not be happy).
What's worse, you have exactly no way to distinguish when it's firefox that
calls kpdf/okular or you from your file manager or anything else, because the
only file you get is the the one in /tmp/whatever, downloaded by firefox (that
kindly does not even provide the helper application the full url (this is
covered by another firefox bug)).
Another solution: copying the file somewhere? Bad, as for the problem above
(impossibility to distinguish when being called by firefox or else) you would
end up copying around your document also for normal (non-firefox) usage
(imagine to copy a big document in a NFS partition, happiness). As above, I
don't think all the kpdf users would be happy for that.

> Is it a good policy to depend BOTH on other programs not tampering with the
> file on the disk AND on the user not moving or removing the file while viewing
> it in kpdf? I would say no. I would say it is better for the program to be
> self-reliant, but it is not my decision to make.

So, you would say that is better to fix *all* the programs that can be
potentially started by firefox, than solving this issue on the firefox side? I
would say no.


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]