2 Replies Latest reply: Mar 3, 2011 9:01 PM by TonyField RSS

    Bridge 5 operational bug Part 2 UPDATED

    TonyField

      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

        • 1. Re: Bridge 5 operational bug Part 2 UPDATED
          TonyField

          It really would be nice if Adobe could provide a "fixit tool" that would update the cache structure to flag the various constructed cache directories as current and up to date in such a way that a rebuild and data duplication would not be done.  This would go a long way to making cache rebuilds from the .BridgeCache files a useful tool.

           

           

          P.S.  This file processing problem did not happen when CS5 was released and I migrated from Bridge CS4 to CS5.  Hopefully a fix can be provided.

          • 2. Re: Bridge 5 operational bug Part 2 UPDATED
            TonyField

            further note.... since I forgot to mention it previously....

             

            If images are accessed ONLY through the Bridge 5 FOLDERS tab, data duplication does not result.