Topic
3 replies Latest Post - ‏2013-01-08T23:23:18Z by SystemAdmin
SystemAdmin
SystemAdmin
849 Posts
ACCEPTED ANSWER

Pinned topic Fix pack upgrade does not preserve symbol scan configuration

‏2012-12-28T23:02:46Z |
It appears that the upgrade process overwrites any updates to the symbol scanner customization. Part of the problem caused by this is that there is no easy way to determine what has been scanned for symbols, when, nor how to just rescan for symbols assets without having to go through deep analysis.

Aside from the silent loss of customization, I think it would be very nice if there where clear stages in the analysis queue, with visibility at the file level, as opposed to container scan, with some staging where files could be prevented from progression before they are thrown into the analyze language and loose their current metadata. The current stages for container scan, import, cleanup... are a bit unclear as to their meaning. May be they do what I am asking for..
In any case, it would be nice to have a stage that says "symbol scanning" and a stage after it with something like "entry to structured scanning". Then the administrator could delete the requests from this last stage.

Something like this is pretty much a requirement for any change in the symbol scan workings, either due to changes in the user scanning configuration or by changes in the product internals related to this area.
Do you understand what I am going after ?
Updated on 2013-01-08T23:23:18Z at 2013-01-08T23:23:18Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    849 Posts
    ACCEPTED ANSWER

    Re: Fix pack upgrade does not preserve symbol scan configuration

    ‏2013-01-01T00:40:15Z  in response to SystemAdmin
    >> there is no easy way to determine what has been scanned for symbols

    Agree... I can only think of querying the database to see if there are symbols for the file. But that will not tell you what symbol scanning controls (reg.ex parms) were used :-(

    >> have a stage that says "symbol scanning"

    Currently the symbol scanning is intertwined into container scan, so that would be hard, but... we are discussing making symbol scanner a default deep scanner for files we do not have detailed analyzers, and populating symbols for those languages we do know well from the data provided by those analyzers (ex: literals, comments etc... ).
    • SystemAdmin
      SystemAdmin
      849 Posts
      ACCEPTED ANSWER

      Re: Fix pack upgrade does not preserve symbol scan configuration

      ‏2013-01-08T22:54:03Z  in response to SystemAdmin
      >> Currently the symbol scanning is intertwined into container scan, so that would be hard,

      IMHO, it is a problem because there can be a ginormous amount of work derived from a (large)container scan. All cross related internally in batches, pending completion posts via REST handshake (if I understand it correctly). Think in terms of a 150K parts container, which is a number I have not made up.

      In the old good times, container scan generated requests in the queue for subsequent process. IMHO including hidden work under the container scan was a mistake that should be redesign. Just my opinion.
      • SystemAdmin
        SystemAdmin
        849 Posts
        ACCEPTED ANSWER

        Re: Fix pack upgrade does not preserve symbol scan configuration

        ‏2013-01-08T23:23:18Z  in response to SystemAdmin
        Right, that is why down the road we are considering making symbol scanner a default deep scanner for files we do not have detailed analyzers, untangling it out from container or classification scan phase.