<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Dave --<div><br></div><div>> [...] <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">which point the sources file no longer lives on rotating media</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Quick comment on this one. :-) Many computers use SSD/Flash storage these days and I am pretty sure that modern operating systems have their tricks with caching bigger files even further without the application ever noticing. However, considering external file scanners scanning for viruses, yes, it can be beneficial to avoid an extra use of some OS file API.</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><br></span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Best,</span></span></div><div><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">Marcel</span></span></div><div class="mb_sig"></div><blockquote class='history_container' type='cite' style='border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;'>
                        <p style='color: #AAAAAA; margin-top: 10px;'>Am 19.01.2022 04:21:20 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style='font-family:Arial,Helvetica,sans-serif'>On Mon, Jan 17, 2022 at 01:17:31PM -0500, David T. Lewis wrote:<br>> Rather that putting a lot of effort into figuring out how to package<br>> the sources file and how to locate sources files in various places<br>> for various different operating systems, why don't we just get rid<br>> of the file entirely?<br>> <br>> Traditionally the sources file is delivered as a disk file separate<br>> from the images file. That is good if you are dealing with small images<br>> and VMs with limited address space, but nowadays our 64-bit release<br>> image is over 50MB in size, and typical working images get much larger<br>> than that. Meanwhile, a compressed sources file is only(!) 6.7MB on disk.<br>> <br>> So rather than use files, just keep the sources in the image. It would<br>> work like this:<br>> <br>> - Load the compressed sources file into an object, hold it in a class var<br>> - If the in-image sources exist, use them, otherwise use file based sources<br>> - Allow the in-image sources to be cleared so that small images or images<br>>   transmitted over the network do not need to carry the sources along<br>> - Existing disk-based sources lookup would work as before<br>> <br>> I actually have this working now, and I am not seeing any problems when<br>> using the in-image sources. The sources file never needs to be reopened<br>> or located from the file system.<br>> <br>> The attached png shows an explorer on the sources file array in my<br>> image after changing over to the in-image compressed sources. The raw<br>> compressed data is highlighted in the explorer.<br>> <br>> If this sounds worthwhile, I'll clean it up a bit and post a change set<br>> or inbox submission.<br>> <br><br>As promised. Try loading DTL-internal-sources-dtl.4 from the inbox.<br><br>The postscript will create a compressed .stc if you do not already<br>have one in your image directory, then load the raw bytes into a<br>holder object in the image. It then reopens the sources files, at<br>which point the sources file no longer lives on rotating media.<br><br>Evaluate "CompressedSources clearCachedSources" to go back to the<br>old-school approach of rooting around through various directories<br>to find a traditional .sources or .stc file. Don't worry, this still<br>works just as well as it ever did.<br><br>Save your image first ... just sayin'<br><br>Dave<br><br><br></div></blockquote>
                                        </div></body>