When I move a mail folder to a different place or when i delete it with the trash, the folders disappear from their previous places (which is what is expected) but if i quit Mozilla (0.9.5 or 0.9.6) and come back in Mozilla the deleted mails are still here and the moved folders are now in two different places (the old and new ones). To really delete mail folders I have to delete them from the Finder.
sounds like a problem with deleting local folders on the mac (or just OS/X?)
Halim, please provide more information. What kind of e-mail account is this, local, POP, or IMAP? If you know what kind of server you're connecting to, provide that as well. What's the name of the folder you're trying to move or delete? What's the Build ID of Mozilla you're using? Try to put together a list of steps to reproduce this problem, from folder creation to the point you encounter the problem.
No mac os x build environment
OK, here are additional informations : I use a POP account. The folder I tried to delete was in fact a subfolder (called "Emplois") in a folder I have previously created called "Listes de diffusion". Mozilla build : 20011112020 (the version for MacOS X) My OS : MacOS X 10.1.1 Step by step : 1 - I put the Emplois subfolder in the trash 2 - Click on Empty Trash in the File menu (the folder disappears from the folders view) 3 - Quit Mozilla 4 - Launch Mozilla again (the folder is still there !!!) (have to delete it from the Finder)
confirming .. build : 2002-01-31-06 mac os x still exists. When you delete the subfolder and empty trash the folder still exists after restart. This is with deleting any subfolder, empty trash and restart. The folder keeps coming back
It's not only under MacOS X, same thing here under MacOS 8.6 OS -> All And IMO this is not "minor".
getting build on mac. will take a look
The fix is to pass PR_FALSE when deleting summary file and mbox because they are just single individual files. Also added a check to make sure we have a .sbd directory before actually deleting it. david, need review for upcoming patch.
wait, should the file spec routines work with PR_TRUE even if the passed-in file isn't a directory?
nsFileSpecMac.cpp ::Delete assumes that if you are passing PR_TRUE it will be a directory, that is why it fails. But we don't need to depend on this getting fixed because in our case these are just single files.
Have we explored the possibility that the mac file spec routine should behave like the windows and linux ones? Otherwise, we should go through all our uses of this method and fix them, and we should probably change the windows and linux routines to assert if they get called in a way that's not going to work on the mac.
All other places in mailnews\ where we are passing PR_TRUE we do check for directory.
Comment on attachment 71388 [details] [diff] [review] proposed fix ok, good, r=bienvenu. I'll leave it up to ccarlen if he wants a new bug filed on the mac behaviour. This still worries me, but as I understand it, mailnews is the only client of nsFileSpec left, and going forward, we should be getting rid of our uses of it too.
I wouldn't file a new bug on the Mac impl of nsFileSpec. The best way to avoid its problems is to not use it. nsIFile is much easier in this regard and consistent among platforms. Its Remove() method checks whether it's a directory and, if not, ignores the recursive flag.
As we know nsFileSpec is deprecated but mailnews still uses it and I don't think any clean up is scheduled for mozilla 1.0/Mach V.
I'm doing some as part of bug 12911 which I'm working on now. Unfortunately, there's still a lot of nsFileSpec usage beyond that.
Comment on attachment 71388 [details] [diff] [review] proposed fix sr=mscott
a=roc+moz for 0.9.9
*** Bug 129513 has been marked as a duplicate of this bug. ***
OK using ap4 commercial trunk build: mac OS 10.1, mac OS 9.2