Skip navigation
TonyField
Currently Being Moderated

Bridge 5 operational bug Part 2 UPDATED

Feb 27, 2011 10:58 PM

This is a follow-up to the note on and may clarify some of the operational observations seen in::

 

http://forums.adobe.com/thread/794019?tstart=0

 

Bridge 5 is duplicating directories of thumbs and previews.  Here is a small partial list of duplicated directories:

 

Volume in drive H is BridgeCache
Volume Serial Number is F03E-BFBE

 

Directory of H:\Bridge5Cache0900\1024

 

2011-02-03  19:33    <DIR>          0001-020D4F6EE74
2011-02-07  02:03    <DIR>          0001-020F29A3CA8

 

2011-02-03  19:39    <DIR>          0201-0309711833E
2011-01-28  02:46    <DIR>          0201-030B17D51E2

 

2011-02-03  19:40    <DIR>          0301-0405EF49525
2011-01-28  03:15    <DIR>          0301-040789847F9

 

2011-02-03  19:40    <DIR>          0401-05055F3F60B
2011-01-28  04:08    <DIR>          0401-050739F24D7

 

2011-02-07  21:18    <DIR>          0501-0609B1F48CC
2011-01-28  01:33    <DIR>          0501-060BD739A10

 


2011-02-26  23:06    <DIR>          aura8E42DD55
2011-01-23  12:49    <DIR>          auraCB12C2D2

 

2011-02-03  18:34    <DIR>          auraEdwoABC9C675
2011-01-23  04:16    <DIR>          auraEdwoFF3C795F

 

2011-02-26  23:29    <DIR>          BluesAtJA837BAA1
2011-01-21  15:42    <DIR>          BluesAtJFCC2058B

 

2011-01-21  16:44    <DIR>          danceatn520465E7
2011-02-19  00:53    <DIR>          danceatn79EC6611

 

2011-02-26  23:37    <DIR>          madi2066804A
2011-02-11  21:51    <DIR>          madi65369FCD

 

             795 Dir(s)  317,227,864,064 bytes free

 

Many more examples can be provided.

 

Each pair of directories contain identical 1024 preview images.  In all cases, the only difference in directory names is the hash code appended to the "primary part" of the directory name.  (In the above, the numeric directory names are of the form nnnn-nnnn)

 

The initial rebuild of the cache was massivly constructed during January 2011.  The more recent directories were constructed when the directories were recently accessed.   Please refer to the above mentioned thread for more details.  This data duplication "explains" some of the operational observations in that thread. Unfortunately, I did not notice this at that time.

 

The directory duplication shows that Bridge 5 is rebuilding thumbs/previews in a new directory even though it has rebuilt the complete cach "very recently" - in particular, the "madi" directory..

 

If I were to interpret this, it seems to me that Bridge computes the hash part of the name in different ways and therefor causes a data duplication and it's associated heavy resource overload when it is least expected.

 

I don't know if this manifestation is work-flow dependent:  I have work-in-progress directories on my workstation and have a master cache associated with these directories.  In all cases, the cache system is built with the export option to generate .BridgCache files. At various times, I copy the work-in-progress directories to my networked storage system.  Subsequently, using an appropriate "archival" master cache, I build the cache for the new directories.  I assume that the initial seed of thumbs/previews is copied from the .BridgeCache files.  The above directory samples are from the "appropriate master cache".

 

 

UPDATE TEST

 

I did a test that just might be reproduceable

 

1. A test directory on the worstation hard drives was created with three image sub-directories using a master cache directory on the workstation.  The caches were build and .BridgeCache files exported.  All viewing was perfectly fine.

 

2. The test directory was copied to a network archive drive.

 

3. The workstation master cache was deleted and a new master cache created.  A single small directory was added to visually acertain that the cache was properly functioning.

 

4. Using the windows "drag and drop" feature, the test directory on the networked archive drive was dropped onto the Bridge 5 desk top icon.  Bridge started immediately with the three sub-directories properly displayed in the "content" panel.

 

5. The bridge "tools/cache/Build and Export Cache was selected to 'Build Cache For Folder "9999-today" and All Enclosed Folders".  The "Export Cache To Folders" was unchecked (since there are already .BridgeCache files in each directory and they are the basis for seeding the master cache).  The cache was constructed with the following results in the 1024 directory:

 

2011-02-27  21:04    <DIR>          20110219BED18138
2011-02-27  21:03    <DIR>          20110224EB4DAE46
2011-02-27  21:02    <DIR>          barasmal0B44C410
2011-02-27  20:57    <DIR>          empty1E10B2FB

 

6.  Clicking on each directory resulted in immediately visible thumbs with no rebuild.

 

7. Each directory was open by an external process with a using ShellExecute() that has the bridge programme and image file reference, for example

 

C:\Program Files (x86)\Adobe\Adobe Bridge CS5\Bridge.exe \\P2\Volume_1\ImageArchive\9999-today\barasmall\tf603683.cr2

 

Two such directories were so opened.  Those directoies has duplicated master cache entries.

 

8. The computer was shut down and restarted.  Bridge was restarted alone (not by another process).  The third directory was open and immediately the cache was rebuilt and a duplicate entry resulted.

 

9. The final content of the 1024 directory in all accessed directorys being duplicated:

 

 

Volume in drive D is extra
Volume Serial Number is 6CEE-8402

 

Directory of D:\Bridge5Cache\1024

 

2011-02-27  21:23    <DIR>          .
2011-02-27  21:23    <DIR>          ..
2011-02-27  21:04    <DIR>          20110219BED18138
2011-02-27  21:11    <DIR>          20110219FB819EBF
2011-02-27  21:23    <DIR>          20110224AE1DB1C1
2011-02-27  21:03    <DIR>          20110224EB4DAE46
2011-02-27  21:02    <DIR>          barasmal0B44C410
2011-02-27  21:09    <DIR>          barasmal78DD828C
2011-02-27  20:57    <DIR>          empty1E10B2FB
               0 File(s)              0 bytes
               9 Dir(s)  313,629,155,328 bytes free

 

This seems rather strange - even though Bridgie created a set of .BridgeCache directories "within the last hour", simply moving the image directories to a new location for archival purposes (and building the master cache) causes Bridge to reconstruct the master caches a second time.  It does not even have the courtesy of removing the now-obsolete thumbs/previews although it does seem to update the modified time of the .BridgeCache files in the image directoies.

 

When the "Compact Cache" option is used, only two of the three duplicated directories were removed - a third remained with all images duplicated.

 

IMHO, this is defeats a significant reason for creating the .BridgeCache files in the image folders.  There is a resource overhead of creating the .BridgeCache files in the first place.  Then, when those files are needed, the image previews and thumbs are copied from the .Bridgecache to the master and  effectively ignored when Bridge 5 completely rebuilds the cache anyway.  I now have a master cache that took weeks of 24 hr per day processing to construct and it is now corrupted with duplicate and useless data - inpinging upon the 500,000 file "limit" for the Bridge master cache.  It also is causing a major time waste while waiting for the rebuild when I need to browse many directories for a number of books I will be publishing over the next year.

 

Thank you

 

tony

 
Replies

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points