refactor recursiveScan function#739
Conversation
Signed-off-by: Ritish Srivastava <121374890+Ritish134@users.noreply.github.com>
|
Hey @Ritish134 -- appreciate the effort here! It seems like we were operating on the same wavelength with the proposed changes; however, I actually included a version of this in #734 as part of the larger migration to a newer Yara API and didn't see this until now. As far as refactoring goes, there are some other areas that could use this attention, namely Let me know if you're interested in either of these. I'm happy to log Issues with further details! |
|
Thanks! @egibs for the update. Sure, I would definitely be interested in working on these areas, so I'll deep-dive in! |
|
Also, if there’s any slightly more complex issue I could help with next, I’d love to take it on. |
Breakdown of recursiveScan function: #497
initializeReportfunction to initialize and configure themalcontent.Reportobject.sync.Onceto ensure that a match (or miss) is processed only once, I CreatedsetMatchHandlingfunction to do that, basically in this :Only the first goroutine to send a result to this channel succeeds due to the buffered capacity of 1.
matchChan := make(chan matchResult, 1)context.WithCancelis used to signal all concurrent goroutines to stop further processing once a match is found.Let me know your thoughts on this @tstromberg
the logic for handling OCI image extraction (including the
imageURIandociExtractPathvariables) moved into the helper functionprepareScanPath.The call to
findFilesRecursivelyis now encapsulated withinprocessPaths. This function is responsible for finding files and managing their subsequent processing.Concurrency Handling logic moved to
processWithConcurrencyFile-specific processing logic into a separate function (
processSingleFile)storeFileReportto store individual file reports andstoreArchiveReportsFor storing multiple file reports from a sync.Map