I uploaded the devel version from today: gopher://gopher.viste.fr/1/temp
In this one I slightly optimized the memory usage, removed LFN support (too dangerous!) and added explicit checks of filenames sanity, before installing any package. Now, any package that contains non-8+3 filenames will be rejected. I am in the process of fixing all the ibiblio packages that contain LFN. I have also set up a small test environment on my PC, and the only packages that fail are the remaining LFN ones (I have yet to repackage 44 of them). I didn't observed any FS corruption while doing tests. Mateusz On 02/12/2015 23:40, Jerome Shidel wrote: > >> On Dec 2, 2015, at 11:14 AM, "Jerome E. Shidel Jr." <jer...@shidel.net> >> wrote: >> >> >>> On Dec 2, 2015, at 3:28 AM, Mateusz Viste <mate...@viste.fr> wrote: >>> >>> I uploaded a new devel version right now: >>> >>> gopher://gopher.viste.fr/1/temp >>> >>> Joe Forster kindly hinted off-list that open watcom comes with a >>> 'doslfnX.lib' library that can be used to transparently enable LFN >>> support within the compiled application. Since the required effort is >>> more than reasonable, I linked FDINST to it, so hopefully (?) FDINST >>> should now support LFN files, and therefore it might solve all the -2 >>> errors that were popping up when trying to unpack LFN files from packages. >>> >>> Mateusz >> >> I will run the complete test on it later today and let you know the results. >> >> But, so far, a quick test is looking good. A couple of packages that caused >> system lockup or crash during the install, remove and reinstall process, >> no longer freeze up the system. :-) :-) :-) >> >> Some, are still throwing errors in a extremely stripped down configuration. >> However, that configuration does not have any LFN support. So, it may >> just be [-2] errors. >> >> Later, I will check the log and also run it under DOSLFN. I will let you know >> the results. >> >>> >>> >>> >>>> On 01/12/2015 19:04, Mateusz Viste wrote: >>>> Hi, >>>> >>>> Here is a new devel version of the FDNPKG package (including FDINST, as >>>> usual). The big change is that I use zlib now, instead of tinfl. >>>> >>>> gopher://gopher.viste.fr/1/temp >>>> >>>> My limited tests show that it doesn't fail any more on neither the >>>> 'lzma' nor 'help' packages, which the previous deflate library was >>>> failing on when compiled to a 16bit target. >>>> >>>> This should solve all the -15 and -9 errors you had (these errors being >>>> "DEFLATE failure" and "CRC mismatch", respectively). >>>> >>>> The -2 errors you reported will NOT be solved ("cannot create file"), >>>> since these are related to LFN handling, and as far as I know, Open >>>> Watcom doesn't support LFN natively (and I don't plan to write my own >>>> INT-based LFN client implementation, nor using a specialized library for >>>> that). Ideally, a FreeDOS package shouldn't contain LFN files, but >>>> unfortunately some software uses non-8+3 filenames in their sources... >>>> No idea how this could be solved 'cleanly' at the package level. >>>> >>>> I do not know whether this devel version will solve troubles related to >>>> freezing and/or inability to reinstall packages. It might solve them, if >>>> TINFL was trashing memory for whatever reason. But it also might be some >>>> FDNPKG bug just as well, or not related to FDNPKG/TINFL at all. I will >>>> have to do more tests, so far I wasn't able to reproduce the behavior >>>> you described. >>>> >>>> Mateusz > > Well, I had run the test without LFN, caching... > > It did not freeze or lockup. > There were multiple issues and about 2500 errors (total). Containing -2,-3,-4 > and -9. > > After adding DOSLFN, there were chkdsk errors and it locked up at sone point. > However, with the system lockups caused by the previous version. There may > have been file system damage. > > While rebuilding the vm, I broke some stuff. Thought I fixed it. But, now > Fdinst is exiting with an errorlevel but no error messages. > > I ran out of time. So, results are not conclusive. I don't know when I will > be able to get back to it. > ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
