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):
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.
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
Output from lsof:
gaim 29484 kyrre 10r REG 3,2 294209 6815794
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.
Interesting - i am beginning to love Unix more and more the more i use
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!
Please re-test with 1.0.2, is behavior any different?
very much indeed still there...
other party was using 1.0, should that have anything to say in this
reciving party has now upgraded. It just imediatly finished.
Bug is definatly still there...
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).
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...)
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.
in the sf tracker i've just been marking file transfer bugs as such
and asking for patches.
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.
I think its still present. What about having that gnome-screenshot-thing wait
1-2 minutes before deleting the file?
Closing because this needs to be fixed upstream and it is not Fedora's sole
responsibility. The suggestion in Comment #11 is terrible.