File Transfer Fails To Unlock File

[spam@weks.net]

When a file transfer completes, it fails to unlock the file and allow me to do anything with it. As of right now, a restart of Adium is required to deal with the files that were transferred. Failure or success does not matter with this. (10.4)

(durin42 note: this is happening on joscar too, and I'm sure we can fix it for joscar....)

(new durin42 note: I'm wondering if this is actually on our side. Mail has a similar bug. Maybe there's a Cocoa framework bug lurking behind this?)

[evands]

This is a libgaim issue.

[evands]

And is not going to be targeted in 0.83.

[carl.norum@…]

Screenshot of error message.

[evands]

Has this been reported to the gaim team? If so, the sf.net bug link should be listed here.

[durin42]

We can fix this on joscar if nothing else, so I'm moving this back to the 1.0 target for the moment so it gets done.

[evands]

I'm not aware of any Adium-side code which would have this effect, so I think it's in a jar somewhere -- assigning to leak.

[MEMark]

When it comes to sending files via MSN at least, most of the time closing the conversation window releases the file that was sent.

[Steven]

Closing the conversation window didn't change anything for me. I still have to quit Adium in order to empty the trash. This is a pretty annoying buy for me :)

[DhruvK]

I dunno if this could be a subset of this ticket or deserves one of its own, but recent SVN builds don't update incoming AIM file transfers too well - i.e. the transfer will finish, but the transfers window won't ever flag it as completed (thus any post-processing such as opening the file or clearing it from the window doesn't happen).

[evands]

DhruvK, that's definitely a separate issue.

[dcrosta]

At least in AdiumX 0.89.1 closing the chat window seems to "release" the file (or whatever terminology is best). For what it's worth,  this gaim bug (1304201) seems to be the closest to this ticket, though it's filed as a win32 bug.

[Alex]

No, it's a joscar thing. I am seing same problem in JClaim. leak needs to take a good look.

Also, if this helps, cancelling a transfer before it really started transfering already has the file locked.

- Alex.

[zacw]

Fixing not-really-a-link links.

[Durandal]

This exists on 1.0b7.

[tick]

We need to figure out what's going on here with 1.2 if possible.

[Zorg]

This is fixed in b17 due to the switch back to libgaim.

[evands]

Are you sure, Zorg? It was a problem with libgaim back when the ticket was first made.

[gbooker]

Even, I believe this is fixed. In my messing with libgaim's file transfer, I have sent several files back and forth. I was able to trash (and empty it) the file after the transfer either completed, cancelled, or failed, without quitting adium.

I recommend this be closed as fixed, but will leave it to you Evan since you are unsure.

[Catfish_Man]

Tested on irc.

[chucker]

Are we sure this is fixed?

I just tried a file transfer with AIM on 1.0/r18816 (i.e., Libgaim), which failed, so I had to cancel it. I cleared it from the File Transfers window, and moved the file to the Trash. However, I cannot empty the Trash; according to Finder, the item "is in use".

$ lsof -n | grep Cate
Adium     10538 chucker  txt      REG      14,2     15818  6572156 /Users/chucker/.Trash/Cate.png

So it appears there are still cases where Adium does not cleanly unlock the file.

[jas8522]

Yeah it's definitely still occuring in 1.1svn. It happens with MSN at the very least. Is it still a libpurple problem?

[durin42]

 http://developer.pidgin.im/ticket/1643 seems to be related to this. I'll try to watch that.

[Robby]

Pidgin Trac is down. Have you experienced this issue recently, Augie?

[trac-robot]

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

[jas8522]

This does still exist, at least with MSN. See:  http://code.google.com/p/msn-pecan/issues/detail?id=37

I don't think I've had it happen with other protocols however...

[jas8522]

This ticket is a lot longer than I thought and more directed towards AIM. Switching this to #6745 which is MSN specific