285296 - saving attachment via drag and drop sometimes gives "file in use" error.

Status: RESOLVED DUPLICATE of bug 253711

(Thunderbird :: Mail Window Front End, defect)

Description

[Eric J. Schwarzenbach]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

Attemping to save an attachment via drag and drop occasionally results in an
error indicating that the file cannot be copied as it may be in use. I'm afriad
this is sporadic and I can't figure how to reproduce it reliably, but it has
happened to me several times, and no the file was not already open. And if it
were, this should not stop a copy from happening if the file is opened for the
copy with readonly rather read-write permissions.

The cases where it happened I had multiple attachements and was multi-selecting
them; I don't know if this is relevant to the problem, but I'd adding this
details FWIW.

Reproducible: Sometimes

Comment 1

[Jeongkyu Kim]

To handle drag and drop, thunberbird copies the file into default folder first
and moves it into target folder later. This bug happens when drag and drop is
quick enough so that thunderbird starts to move the file before copying is done.
To avoid this bug, thunderbird should be able to check status of copy operation.

Comment 2

[OstGote!]

Looks like bug 253711.

Comment 3

[Eric J. Schwarzenbach]

(In reply to comment #2)
> Looks like bug 253711.

I don't know if it means this bug is different from that one or not, but that
one seems to specify that it only happens with IMAP, and this bug ocurred with POP.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> (In reply to comment #2)
> > Looks like bug 253711.
> 
> [...] that one seems to specify that it only happens with IMAP, and this bug
> ocurred with POP.

That could be because my brief testing with dragging from POP didn't encounter 
whatever race condition may be behind this bug.  If you find that after getting 
the error, the file actually exists either in your Temp directory or, more 
likely, in the *parent* of the temp directory (viz. bug 252479), then this 
should be marked a dupe of 253711.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Jeongkyu Kim]

Hi QA,

This seems to be a dupe of bug 253711 (see comment #7 in bug 253711). Would 
someone confirm this and mark it as dupe?

Comment 7

[Mike Cowperthwaite]

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