The 'degenerate' case here of course is a file scan for a Magic String, potentially parametric, which returns the appropriate image factory... On Tue, Jan 28, 2014 at 2:22 PM, Rob Eaglestone <robert.eaglestone@gmail.com > wrote: > > the major problem with that approach is that it doesnt work on disks >> that are >> > completely filled with data (which isnt really unlikely, lots of cracks >> and >> > demos use the dirtrack for files, for example) - which rules it out as a >> > generic solution. >> >> I think another big advantage is that it modifies the data contents >> themselves. This is something I personally do not want to have. For me, >> one use of a disk image is to preserve data that was once on a real >> disk. Here, changing the disk data that should be preserved is no >> option. >> > > Granted. There are disks which ought never be modified. > > However, it seems like the best solution is going to follow The Burrito > Principle (80% of the meat is in 20% of the burrito). > > In other words, a solution which will work on 80% of all diskette images, > and which yields 100% backwards compatibility for those diskettes, is most > likely the one to pick. So, fiddling with Directory Track N-1 is a valid > solution. Tacking on a "trailer" block is more robust but slightly less > valid (programs might choke on the file size). > > > > > On Tue, Jan 28, 2014 at 1:47 PM, Spiro Trikaliotis < > ml-cbmhackers@trikaliotis.net> wrote: > >> Hello, >> >> * On Tue, Jan 28, 2014 at 07:59:10AM +0100 Groepaz wrote: >> >> > the major problem with that approach is that it doesnt work on disks >> that are >> > completely filled with data (which isnt really unlikely, lots of cracks >> and >> > demos use the dirtrack for files, for example) - which rules it out as a >> > generic solution. >> >> I think another big advantage is that it modifies the data contents >> themselves. This is something I personally do not want to have. For me, >> one use of a disk image is to preserve data that was once on a real >> disk. Here, changing the disk data that should be preserved is no >> option. >> >> Also, someone suggested changing the BAM, because it can be rebuilt by >> "V"alidate. No, I do not like this, because the BAM contains info, too. >> There can be an error (accidentially or intentionally) that might serve >> a purpose. >> >> Thus, please, DO NOT MODIFY THE DATA CONTENTS SOMEONE MIGHT WANT TO >> PRESERVE. >> >> I do not like to have it optional, because people will not know about >> these options, and they might accidentially use it. >> >> If people do not like a container format, another option might be to add >> another file beside the original one. For example, have a file >> >> MYSUPERDUPERDISK.d9060 >> >> and a meta-file >> >> MYSUPERDUPERDISK.d9060.meta >> >> (or, if you want to play with ADS on Windows, use >> MYSUPERDUPERDISK.d9060:meta ;) >> >> Regards, >> Spiro. >> >> -- >> Spiro R. Trikaliotis >> http://www.trikaliotis.net/ >> >> Message was sent through the cbm-hackers mailing list >> > > Message was sent through the cbm-hackers mailing listReceived on 2014-01-28 21:01:18
Archive generated by hypermail 2.2.0.