Placeholder bug for the file cache: The file cache is largely done (written by yixiong.zou@intel.com), but it needs final review and testing. Once the code is checked in, the ifdef FILE_CACHE_IS_READY lines in nsCacheManager.cpp will need to be enabled.

Bulk move of all Cache (to be deleted component) bugs to new Networking: Cache component.

Assigning fur's cache bugs to Gordon. He can split them up with davidm.

The nsIFileSpec is phasing out right? Should we change the Cache API accordingly?

Will it be in for M14 ? This is bugging a lot of people. Problems include: 1) Fetching linked documents repeatedly (CSS, JS, etc) 2) 'View Source' and 'Save Page' fetching the document again. etc.

*** Bug 26470 has been marked as a duplicate of this bug. ***

David is doing this now.

Diff to fix DBM file creation for Mac: Index: hash.c =================================================================== RCS file: /cvsroot/mozilla/dbm/src/hash.c,v retrieving revision 3.10 diff -c -2 -r3.10 hash.c *** hash.c 2000/01/26 01:35:12 3.10 --- hash.c 2000/02/17 04:21:38 *************** *** 52,55 **** --- 52,56 ---- #ifdef macintosh #include <unix.h> + #include <Errors.h> #else #include <fcntl.h> *************** *** 168,172 **** new_table = 0; ! if (!file || (flags & O_TRUNC) || (stat(file, &statbuf) && (errno == ENOENT))) { if (errno == ENOENT) --- 169,179 ---- new_table = 0; ! if (!file || (flags & O_TRUNC) || (stat(file, &statbuf) && ! #if defined (macintosh) ! (errno == fnfErr) ! #else ! (errno == ENOENT) ! #endif ! )) { if (errno == ENOENT)

Here are a few comments on the getParent patch, which I hope are helpful (I hope my Unix knowledge isn't too rusty): ! ! nsCString parentPath = mWorkingPath; Should use nsCAutoString here to avoid a malloc for short-ish (<64 char) paths. ! ! PRInt32 offset = parentPath.RFindChar('/'); ! ! if (offset == -1) ! return NS_ERROR_FILE_UNRECOGNIZED_PATH; ! ! parentPath.Truncate(offset); Unix allows multiple slashes between component (or did, when I used to hack on namei, aka lookuppn or pn_lookup). To handle that, you might do the RFind, then decrement offset and check whether it is < 0 or the char at offset is not a slash. My nsStr*.h memory is too poor to sketch the code, but it should be not too bad. One tricky boundary: naive code would make "" be the parent path of "/", but in Unix (AFAICR), "" means "." (current working directory). For the root directory I think getParent should return the selfsame root directory, to match the hard link ".." in that dir. ! ! nsCOMPtr<nsILocalFile> localFile; ! nsresult rv = NS_NewLocalFile(parentPath.GetBuffer(), getter_AddRefs(localFile)); ! ! if(NS_SUCCEEDED(rv) && localFile) This is good belt-and-braces sanity checking, but I'm curious whether NS_NewLocalFile is spec'd to return non-null localFile on successful rv code? ! { ! return localFile->QueryInterface(NS_GET_IID(nsIFile), (void**)aParent); ! } ! return rv;

Clearing PDT- to trigger re-evaluation by PDT team based on the following new information: 27763 (which is beta1 PDT+) now depends on 21100, because according to av, gagan and amusil said that we rely on disk cache to get the notification needed to fix 27763. (And 27763 is a blocker for Java support in beta1.) If this information about the dependency of 27763 on 21100 is correct, then 21100 should be beta1 PDT+ so long as 27763 is. (By the transitive rule of PDT+ for dependencies.)

Spoke with warren, he will investigate to give PDT more info.

Putting on PDT- radar for beta1. No time left per phil.

Marking beta2.

Moving to M15.

Moving what's not done for M15 to M16.

Turned on the cache marking fixed will open new bugs for any problems

marking verified - file cache is in