Closed Bug 296256 Opened 19 years ago Closed 19 years ago

Sanitize Deer Park on Shutdown leaves cache files.

Categories

(Firefox :: Settings UI, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: miket03, Unassigned)

References

Details

(Keywords: qawanted, regression)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

Selecting the Cache in Sanitize Settings - Sanitize at shutdown does not delete
the cache files when you close Deer Park. The files are moved to
"cachedir"\cache.trash\trash\cache but remain on disk.

Sanitizing manually or Clear Cache seems to actually remove the files.

Reproducible: Always

Steps to Reproduce:
1. Open Tools - Options - Privacy
2. Select Sanitize Settings.
3. Mark Cache
4. Mark Sanitize on Shutdown. Set other choices as you wish.
5. OK out of Options
6. Browse for a while.
7. Close Deer Park.

Actual Results:  
"cachedir"\cache is cleared (only indexes remain) but everything that was there
has been moved to "cachedir"\cache.trash\trash\cache

Expected Results:  
All cache files (except default indexes) are removed.
Works for me in Mac OS X 10.2.8
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050601
Firefox/1.0+

Maybe you're seeing bug 284086 ? Or, since those files are actually deleted by a
thread (after being moved to cache.trash), maybe Firefox didn't wait until the
thread was finished ?
(In reply to comment #1)
> 
> Maybe you're seeing bug 284086 ?

Nope. Main window is the only window open.

> Or, since those files are actually deleted by a
> thread (after being moved to cache.trash), maybe Firefox didn't wait until the
> thread was finished ?

Sounds reasonable but I sure don't know.

This could possibly be a dupe of bug 265028 - do you receive any errors in your
Javascript console?
(In reply to comment #3)
> This could possibly be a dupe of bug 265028 - do you receive any errors in your
> Javascript console?

No errors on shutdown although with the js console open Sanitize on close
doesn't run when the main window is closed.

Clear cache doesn't seem to display the occasional issue described in that bug
in "1.1". I have seen it in 1.0.x.
This is probably fixed by attachment #192644 [details] [diff] [review] for bug #284086 - please retest
after check in.
Depends on: 284086
(In reply to comment #5)
> This is probably fixed by attachment #192644 [details] [diff] [review] [edit] for bug #284086 - please
retest
> after check in.

Perhaps you should set blocking1.8b4 on #284086 so the patch gets "prompter"
attention.
(In reply to comment #6)
> (In reply to comment #5)
> > This is probably fixed by attachment #192644 [details] [diff] [review] [edit] [edit] for bug #284086 -
please
> retest
> > after check in.
> 
> Perhaps you should set blocking1.8b4 on #284086 so the patch gets "prompter"
> attention.

I've no authority to set a blocking flag, but I can request it (not sure if this
may change the "promptness" of attention, though).
(In reply to comment #5)
> This is probably fixed by attachment #192644 [details] [diff] [review] [edit] for bug #284086 - please
retest
> after check in.

Tested after check-in on 1.8 branch, and uninstalled Adblock per note in that
bug. The cache.trash directory no longer appears but NO files are removed from
the cache on shutdown.
(In reply to comment #8)
> (In reply to comment #5)
> > This is probably fixed by attachment #192644 [details] [diff] [review] [edit] [edit] for bug #284086 -
please
> retest
> > after check in.
> 
> Tested after check-in on 1.8 branch, and uninstalled Adblock per note in that
> bug. The cache.trash directory no longer appears but NO files are removed from
> the cache on shutdown.


More testing shows that setting browser.cache.disk.parent_directory to a custom
choice caused this patch to fail. The setting had no effect on the original
report. I'd made that change so it was easier to watch the cache folder. Since
this is a custom setting that is rarely used, I'm marking this fixed.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
This bug is back in today's branch build: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b5) Gecko/20050920 Firefox/1.4

It was not in yesterday's (20050919) build. My guess is bug 308384
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Keywords: regression
(In reply to comment #10)
> This bug is back in today's branch build: Mozilla/5.0 (Windows; U; Windows NT
> 5.1; en-US; rv:1.8b5) Gecko/20050920 Firefox/1.4
> 
> It was not in yesterday's (20050919) build. My guess is bug 308384

And backing out the changes in bug 308384 makes clearing the Cache on shutdown
work again.
Flags: blocking1.8b5?
This works for me in the latest trunk build, as far as I can tell.
(In reply to comment #12)
> This works for me in the latest trunk build, as far as I can tell.

Using today's branch build it works maybe 50% of the time.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050926 Firefox/1.4

dir Cache.Trash /s
...
 Directory of D:\Documents and Settings\...90fzj.slt\Cache.Trash

09/26/2005  10:35 PM    <DIR>          .
09/26/2005  10:35 PM    <DIR>          ..
09/26/2005  10:35 PM    <DIR>          Trash
               0 File(s)              0 bytes

 Directory of D:\Documents and Settings\...90fzj.slt\Cache.Trash\Trash

09/26/2005  10:35 PM    <DIR>          .
09/26/2005  10:35 PM    <DIR>          ..
09/26/2005  10:35 PM    <DIR>          Cache
               0 File(s)              0 bytes

 Directory of D:\Documents and Settings\...90fzj.slt\Cache.Trash\Trash\Cache

09/26/2005  10:35 PM    <DIR>          .
09/26/2005  10:35 PM    <DIR>          ..
09/26/2005  10:35 PM           114,176 _CACHE_001_
09/26/2005  10:35 PM           104,448 _CACHE_002_
09/26/2005  10:35 PM           622,592 _CACHE_003_
09/26/2005  10:35 PM             8,468 _CACHE_MAP_
               4 File(s)        849,684 bytes

If I visit more pages then more files remain.
Keywords: qawanted
This WFM on trunk and 1.4 Fx builds from 0929 on Windows
WFM per Tracy's analysis.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Flags: blocking1.8b5?
Resolution: --- → WORKSFORME
Depends on: 321833
You need to log in before you can comment on or make changes to this bug.