Bug 132478 - Problems with dragging a picture from print-screen-popup to gaim
Summary: Problems with dragging a picture from print-screen-popup to gaim
Alias: None
Product: Fedora
Classification: Fedora
Component: gaim (Show other bugs)
(Show other bugs)
Version: 2
Hardware: All Linux
Target Milestone: ---
Assignee: Warren Togami
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-13 21:03 UTC by Kyrre Ness Sjøbæk
Modified: 2007-11-30 22:10 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-04 10:27:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Kyrre Ness Sjøbæk 2004-09-13 21:03:47 UTC
Description of problem:
I do extremely often use a feature in gaim, which in combination with
another feature in gnome-panel-screenshot is extremely usefull: when
you hit printscreen, gnome-panel-screenshot gives you a preview, and
if you drag that preview into gaim it initiates a filetransfer of this

This works by creating a a .png file in /tmp, and gaim then tries to
send this file. Problem arises when i hit cancel on
"gnome-panel-screenshot" BEFORE the other party accnowledges - then
gnome-panel-screenshot does it duty and deletes it.

But if the other party accnowledges before you hit cancel, it still
gets deleted - and transfered... It seems that the file can be
deleted, but still exist - to gaim, but not to ex cat...

The file is then sucessfully transfered, and gets deleted when gaim is

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1.hit "print-screen" while in gnome
2.drag the preview over to the conversation window in gaim
3.File transfer proposed
4.hit "cancel" in the preview-window
5.Other party hits accept. Gets an empty (NULL?) file - dowloaded at
"infinite" speed - but nothing is sent.
Actual results:
nothing sent

Expected results:
gaim should open the file as soon as it gets the order to transfer it,
which will ensure both the cleanup AND the transfer, or at least an
error message...

Additional info:

Output from lsof:
gaim      29484   kyrre   10r   REG        3,2   294209    6815794
/tmp/gnome-panel-screenshot-1946205200/Skjermdump.png (deleted)

Comment 1 Daniel Reed 2004-09-13 21:35:51 UTC
As a data point, many other chat clients (including ircII derivatives
and naim) will exhibit similar behavior: The file is statted to
determine file size, but is not opened until file transfer begins.

In a Unix-like environment, files exist on disk independently from
their location in a directory tree. Hardlinks work by having multiple
entries in the directory tree reference the same file. Files can be
moved from one directory location to another by simply changing a
link; they do not need to change locations on disk.

Files are kept on disk until all "references" to them have been
removed. References include entries in a directory tree linking to the
file as well as instances of the file being opened by a running
process. Once a file has lost all directory references (meaning you
have used the rm command to remove all links to the file), it can
typically not be recovered. However, it will continue to exist in
whole until the last process that has it open closes it. This is why
gaim is able to continue to deliver the file even after the directory
link has been removed.

Comment 2 Kyrre Ness Sjøbæk 2004-09-14 18:12:14 UTC
Interesting - i am beginning to love Unix more and more the more i use
it :)

But what if gaim simply opened the file the moment it got the message
to transfer it? To copy it to its own tmp would be idiotic - some
moron could attempt to transfer a multi-GB file over IM... - but if
gaim had just opened it at once, there would be no problem - the OS
will take care of the details.

But what if the directory which contains the file is deleted?

Btw. i also love dragging stuff into the conversation window - files
from nautilus, mails from evolution, music from rythmbox,
print-screens etc. It is just so laughingly perfect! Only problem is
that i break GAIM all the time... Think i got somthing like 4 out of 6
bugzilla bugs for gaim in FC2 now!

Comment 3 Warren Togami 2004-10-31 09:02:45 UTC
Please re-test with 1.0.2, is behavior any different?

Comment 4 Kyrre Ness Sjøbæk 2004-10-31 19:13:23 UTC
very much indeed still there...

other party was using 1.0, should that have anything to say in this

Comment 5 Kyrre Ness Sjøbæk 2004-10-31 19:42:25 UTC
reciving party has now upgraded. It just imediatly finished.

Bug is definatly still there...

Comment 6 Daniel Reed 2004-11-06 18:47:36 UTC
This is a behavior of the upstream gaim project, and is not specific to Red
Hat's packaging. Several upstream developers will read this report, so I will
leave it up to one of them to handle it from here (or close the report if the
behavior described is not considered a bug).

Comment 7 Kyrre Ness Sjøbæk 2004-11-06 19:21:23 UTC
The behaviour is definatly a bug. Argh... where is my sf.net
password... (I created it once to give some info on a gaim bug which
was moved from RH bugzilla...)

Comment 8 Ethan Blanton 2004-11-06 19:39:35 UTC
There is no reason to file a sourceforge bug, as Mr. Reed already
pointed out.  Several Gaim developers monitor this forum.  I agree
that this is a bug, Gaim should at the least notify you that the file
could not be sent.  File transfer and related behaviors are not
generally very high on the priority list, so I don't know when this
might be fixed, but it is certainly something we want to take care of.


Comment 9 Luke Schierer 2004-11-07 01:38:58 UTC
in the sf tracker i've just been marking file transfer bugs as such
and asking for patches. 

Comment 10 Matthew Miller 2005-04-26 15:32:17 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 11 Kyrre Ness Sjøbæk 2005-08-25 19:51:56 UTC
I think its still present. What about having that gnome-screenshot-thing wait
1-2 minutes before deleting the file?

Comment 12 Warren Togami 2005-09-04 10:27:17 UTC
Closing because this needs to be fixed upstream and it is not Fedora's sole
responsibility.  The suggestion in Comment #11 is terrible.

Note You need to log in before you can comment on or make changes to this bug.