If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Local trashed or moved folders still there

VERIFIED FIXED in mozilla1.0

Status

MailNews Core
Backend
P2
normal
VERIFIED FIXED
16 years ago
9 years ago

People

(Reporter: halim.boussoualine, Assigned: Navin Gupta)

Tracking

Trunk
mozilla1.0
PowerPC
Mac System 9.x

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
sounds like a problem with deleting local folders on the mac (or just OS/X?)
Assignee: bienvenu → naving
Component: Mail Database → Mail Back End

Comment 2

16 years ago
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.
(Assignee)

Comment 3

16 years ago
No mac os x build environment
Keywords: helpwanted
(Reporter)

Comment 4

16 years ago
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)

Updated

16 years ago
QA Contact: esther → sheelar

Comment 5

16 years ago
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
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: nsbeta1 → nsbeta1+
Priority: -- → P2

Comment 6

16 years ago
It's not only under MacOS X, same thing here under MacOS 8.6

OS -> All

And IMO this is not "minor".

Updated

16 years ago
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 7

16 years ago
getting build on mac. will take a look
Severity: minor → normal
Keywords: helpwanted
OS: MacOS X → Mac System 9.x
(Assignee)

Comment 8

16 years ago
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. 
Summary: trashed or moved folders still there → Local trashed or moved folders still there
(Assignee)

Comment 9

16 years ago
Created attachment 71388 [details] [diff] [review]
proposed fix

Comment 10

16 years ago
wait, should the file spec routines work with PR_TRUE even if the passed-in file
isn't a directory?
(Assignee)

Comment 11

16 years ago
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. 

Comment 12

16 years ago
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.
(Assignee)

Comment 13

16 years ago
All other places in mailnews\ where we are passing PR_TRUE we do check for
directory. 

Comment 14

16 years ago
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.
Attachment #71388 - Flags: review+
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.
(Assignee)

Comment 16

16 years ago
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 18

16 years ago
Comment on attachment 71388 [details] [diff] [review]
proposed fix

sr=mscott
Attachment #71388 - Flags: superreview+
a=roc+moz for 0.9.9
Keywords: mozilla0.9.9+
Attachment #71388 - Flags: approval+
(Assignee)

Comment 20

16 years ago
fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 21

16 years ago
*** Bug 129513 has been marked as a duplicate of this bug. ***

Updated

16 years ago
QA Contact: sheelar → laurel

Comment 22

16 years ago
OK using ap4 commercial trunk build: mac OS 10.1, mac OS 9.2
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.