Closed
Bug 365814
Opened 19 years ago
Closed 17 years ago
nsIMessenger.saveAttachmentToFolder doesn't work properly (save in parent directory of nsIFile last argument)
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: intendentedelleacque, Unassigned)
Details
(Whiteboard: closeme 2008-10-21)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier:
I'm trying to write an extension that uses the method saveAttachmentToFolder of nsIMessenger interface and I think to have found that this methods works properly just on win xp.
Infact I get these beahviours:
1) on winxp --> it saves properly the attachment in "nsILocalFile destFolder" and return it properly as nsILocalFile;
2) on linux debian --> it saves the attachment in the parent directory of "nsILocalFile destFolder" and not in "nsILocalFile destFolder"; the return value is correct;
3) on win millenium --> it doesn't save the attachment (fails without no error message), but return a value of a (not existing) nsILocalFile with a path equal to the parent directory of "nsILocalFile destFolder" plus the attachment name.
I couldn't try with mac osx.
Reproducible: Always
Comment 1•19 years ago
|
||
I think you may want to provide some more sample code for anyone to be able to say anything about this... (and you did try with a recent 2.0 build/trunk?
| Reporter | ||
Comment 2•19 years ago
|
||
Sure, here is an example:
---CODE BEGINNING---
function test(aAttachment) {
// aAttachment is an object, equal to the object used in openAttachment
// native function
var temp = Components.classes["@mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties)
.get("TmpD", Components.interfaces.nsIFile);
// This is on Linux the directory /tmp, on win it dipends from the versions,
// on WinMe is C:\Windows\Temp, on WinXP it is C:\Documents And
// Settings\MyUserName\Local Settings\Temp
var tempfile = messenger.saveAttachmentToFolder(aAttachment.contentType, aAttachment.url, encodeURIComponent(aAttachment.displayName), aAttachment.messageUri, temp);
// messenger is nsIMessenger interface
// Here is my problem: the method saveAttachmentToFolder saves
// the attachment in directory pointed to the variable "temp" just on WinXP
//
// On Linux it tries to save in the root directory /
// (and of course it can fail, if you've not permissions
// to write there. Notice that if I call
//
// temp.append("something")
//
// before calling saveAttachmentToFolder, the method saves in /tmp
// I made some other tests and the result is always that the method on linux
// tries to save in the parent directory of its last arguments (here "temp");
//
//
// On WinMe the function fails without no error message
var tempfilepath = tempfile.path;
// On WinXP this is equal to C:\Documents And
// Settings\MyUserName\Local Settings\Temp\AttachmentName
// (existing and correct)
//
// On Linux this is equal to /AttachmentName
// (existing file if you can write on the root)
//
// On WinMe this is equal to C:\Windows\AttachmentName
// (some beahviour of Linux, but this file doesn't exist)
---END CODE---
I tried with TB 1.5.0.9 and with TB version 2 beta 1 (20061206) with the same result
| Reporter | ||
Comment 3•19 years ago
|
||
Sorry I forgot of course a } at the end of my code...
| Reporter | ||
Comment 4•19 years ago
|
||
Sorry again, I've been able to test again the method on WinXP and I've noticed that also on WinXP it saves in the wrong directory (parent directory of the nsIFile), so here is the sample code with the right comments:
---CODE BEGINNING---
function test(aAttachment) {
// aAttachment is an object, equal to the object used in openAttachment
// native function
var temp = Components.classes["@mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties)
.get("TmpD", Components.interfaces.nsIFile);
// This is on Linux the directory /tmp, on win it dipends from the versions,
// on WinMe is C:\Windows\Temp, on WinXP it is C:\Documents And
// Settings\<MyUserName>\Local Settings\Temp
var tempfile = messenger.saveAttachmentToFolder(aAttachment.contentType,
aAttachment.url, encodeURIComponent(aAttachment.displayName),
aAttachment.messageUri, temp);
// messenger is nsIMessenger interface
// Here is my problem: the method saveAttachmentToFolder saves
// the attachment not in directory pointed to the variable "temp"
// but in its parent directory
//
// For ex. on Linux it tries to save in the root directory /
// (and of course it can fail, if you've not permissions
// to write there). Notice that if I call
//
// temp.append("something")
//
// before calling saveAttachmentToFolder, the method saves in /tmp
// I made some other tests and the result is always that the method
// tries to save in the parent directory of its last arguments (here "temp");
//
//
// On WinMe the function seems to fail without no error message
var tempfilepath = tempfile.path;
// On WinXP this is equal to C:\Documents And
// Settings\MyUserName\Local Settings\AttachmentName
// (existing file, but it should be C:\Documents And
// Settings\MyUserName\Local Settings\Temp\AttachmentName)
//
// On Linux this is equal to /AttachmentName
// (existing file if you can write on the root,
// but it should be /tmp/AttachmentName)
//
// On WinMe this is equal to C:\Windows\AttachmentName
// (some beahviour of Linux, but this file doesn't exist)
}
---END CODE---
Summary: nsIMessenger.saveAttachmentToFolder doesn't work properly on os different from winxp → nsIMessenger.saveAttachmentToFolder doesn't work properly (save in parent directory of nsIFile last argument)
Updated•17 years ago
|
Assignee: mscott → nobody
Comment 5•17 years ago
|
||
if anyone still see this problem using a current version please comment with your version number and steps to reproduce.
if you no longer see the problem, please cite your version and close the bug or comment
Whiteboard: closeme 2008-10-21
Comment 6•17 years ago
|
||
RESO INCO per lack of response to last question. If you feel this change was made in error, please respond to the bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•