Bridge CS6 (Win7) seems to delete thumbnail cache entries for no apparent reason. My cache system was fully build under Bridge CS5. I have recently installed the beta version of ACR for CS5.
I have 700,000 images in bridge spread over two bridge index systems on networked archive drives (to keep within the 500,000 image max image count). In my "currently in use" Bridge Cache, Bridge 6 deleted all of the thumbnail (256) directories however all of the preview (1024) directories still seem to exist. There are now only 7 directores in the 256 directories and they were exactly those visited by Bridge6. The 500+ directories in the 1024 directory seem to remain (however, I have no convenient way to determine if they are complete). The 1024 directories contain 150,000 images and the "revised" 256 directories contain only 4,000 images.
Reconstrucion of the Bridge cache would take a few elapsed days of constant processing - speed limited by the network I could restore my Bridge Cache to a previous status point, however there is no reasonable way to automagically rebuild just those "new" things that are missing. I do not know if tools/cache/build and export cache is sufficiently intelligent to do this efficiently. Yes, I do have the .BridgeCache files recorded in all directories, however Bridge seems to effectively reprocess all images and most of the anticipated speed advantage of rebuilding cache from the .BridgeCache seems to be lost. My assumption was that the .BridgeCache files contain all preview and thumnail image and that is only about 100-500MB of data per set - which should be adequate to quickly rebuild the working bridge cache - however much more processing seems to be needed and this is indicated by watching Task Manager.
In this light, it would be nice if Bridge would provide a text file audit trail of the computed directory hash code directory names (such as TatianaL731C0F2F used in the 1024 and 256 directories) to the actual directory (such as //P2/Volume_1/ImageArchive/1042-2012Jan06/TatianaLingerie), it would be somewhat easier to know which cache entries must be rebuilt, particularly if the directory creation dates are also recorded. Alternatively, it would be nice if the hash code could be deconvoluted to the real directory name.
Unfortunately, I did not back up my master cache before installing and trying CS6 - my error I should have realized that the new 64bit edition of Bridge was a considerable upgrade.
Follow-up to the above regarding CS5 and CS6 compatibility..... a clean, isolated test.
Win7-64 bit, SP1 with all updates. System was restarted. The BridgCache information was deleted - in other words, a clean start for Bridge. An empty bridge cache directory was used. The following was noted:
.Bridge 5 was started. Three directories were visited: "Cynthia", "david", and "empty". Bridge 5 created the files:
Bridge 5 was terminated. The expected directories in both the "256" and "1024" directores were created. However, the directory D0F7DAB6B is spurrious - it contains 5 "random images" that were never accessed - and I have no idea why this directory exists.
Bridge 6 was started using the same BridgeCache directory as above, The previously directory "empty" was opened.. Immediately, all other directories were deleted and only references to "empy" were seen as illustrated in:
This implies that Bridge 6 cache files are not compatible with Bridge 5 cache files.
Is this an expected feature? Does that mean that, if you convert to Photoshop/Bridge CS6, all cache files must be rebuilt?? If so, IMHO, this is unacceptable when you have 700,000 images on s 10 terabyte archive built in CS5. It would be a 5 day continuous computer process to reconstruct a complete archive and destroy the user's ability to conveiently use Bridge as a reliable contact sheet of all images taken. File compatibilty, release to release of Bridge, is very important when using bridge as a document archiving system.
I also notice that, for those cache entries created by Bridge 6, Bridge 5 has no problems accessing the 6-created entries. No rebuild from 6 to 5 is needed. However, if you revisit Bridge 6 after visting Bridge 5, all of the cache is deleted AGAIN!!!
Saw your post on DPR, reply here also because it may be more useful. On a quick try, I couldn't really replicate this problem. I did -I hope- the same experiment. It seems to me Bridge 6 overwrites the folders and the jpg's. I can see that from the timestamp, and also the files in the 1024 folder are rendered a bit sharper when previewed. But CS6 did not delete cachefolders for image folders that were not visited.
BTW: in my normal setup, I use the default path [users ... appdata .../adobe/bridge CS5] and CS6 copied that setting, creating a new folder structure .../bridge CS6. The latter only has folders the imagefolders visited so far.
I'm really sorry to hear that you lost cache of so many files. I can reproduce your issue. The reason is Bridge has a design to delete and re-create 256, 1024, full and data folder in the cache folder at the first launch after the cache folder is changed. So for now, you may need to regenerate the cache. And as in CS6, Bridge change the database from MySQL to SQLite, so even your CS5 cache folder is their, Bridge CS6 also need to regenerate the cache as these folder information is not in the database file.
Thanks for reporting the issue and sorry for the inconvinience!
Thanks for the information Chun Xia. There is really no problem in my case at present since I do have very current backups of the bridge cache files and the missing information was easily recovered in about 4 minutes of file copy and 1/2 hour of re-processing.
Since the Bridge Cache system has changed, that means I will have to rebuild the entire cache structure for 700,000 images. That will take about a week of computer time running 24 hours a day.to reconstruct the master cache and I will probably have to acquire a new computer just for this operation.
I assume the .BridgeCache files in each directory are fully serviceable to allow "fast" cache construction - if not, the week of processing will be extended to two or more weeks.
An Asset Management system such as Bridge should not force the user to go through this on a regular basis. Because of changing formats, I will be going through the cache rebuild for the thrid or fourth time since Bridge was first introduced. At least a cache conversion programme should be provided to minimize the impact. This would, in my case, change a week of work to rebuild down to less than an hour of data conversion.
Of course, I cannot do this reconstruction until the official release is available - which, I assume, is reasonably soon. I do hope you will provide reasonable and detailed documentation about this to the general user - in particular, warning them that they should NOT use to Bridge 5 Cache files and also a strategy of running Bridge 5 and Bridge 6 in parallel and/or to convert entirely to Bridge 6. This is obviously a simple thing to do, however the users must be aware of the system implication of implementing Bridge 6.
It would be very useful to change the "Cache Size" in the preferences to allow for an unrestricted number of cache entries or at least expand the number of entries from the 500,000 entries to 1,000,000 or 2,000,000. This would avoid the necessity of creating multiple cache structures for those people who have extensive requirements. I know of a couple of photographers who are already getting close to the 500,000 file limit and they are not aware of the complications that can arise.
A very useful feature would allow Bridge to view the 256/1024 files in browse mode even if the master data is off-line and temporarily not available. I think this feature is present in Lightroom. This would be very useful when I am searching for images and documents to be include in another set of books I am publishing.
Another useful information screen should be implemented in Bridge 6. This, among other potentially useful items, should provide statistics about the number of entries in the cache structure broken out by type of document. I am sure a few other statistical items would be useful. This would help the user manage the cache size brick wall and/or the deletion of old cache entries to make way for new entries. Certainly the count of documents can be easily determined directly from the Windows directory property screen in either the 1024 or 256 directories - it just would be nice to see this as a Bridge statistic
Take care, and thanks again for the reply.