New Disk Image Editor

crj · Post by **crj** » Thu Mar 29, 2018 3:40 pm

It's actually pretty unappealing that the .INF technique doesn't cope with spaces in filenames. Also, that the file has a .INF extension but isn't in INF format. Also, that finding a file by name is O(n) on the number of files in the directory.

I mean yes, if it's become a de facto standard it has to be supported for interface purposes, but I'm unconvinced it was ever a sound engineering choice, let alone the best choice now.

simonm · Post by **simonm** » Fri Mar 30, 2018 12:41 am

^^ this. I mean, .inf files do get a job done, but I've never really warmed to the idea of them. And spaces in filenames really isnt even a thing anymore. So a neat tool that lets me pack all my acorn files into a nice image, preserving file types etc., instead of lots of bitty PC host files, sounds like a pretty swell idea.

crj · Post by **crj** » Fri Mar 30, 2018 3:54 am

I've had quite a few thoughts in this area. I should probably make a separate posting about them when it's not 4am. /-8

yellowpig · Post by **yellowpig** » Fri Mar 30, 2018 9:47 am

There have been a number of suggestions in these posts, and I will try to implement some of them:

The comments about a different character correspondence make sense, and would be easy to implement. I might make this an option, because I think the current way of doing things also has a degree of logic to it.
There has been quite a bit of discussion about .inf files. I still don't like the result of having one .inf file for every actual file, but I accept that this is a well-established way of doing things. Likewise, the format of such files has some tradition to it. I prefer the idea of just one information file per directory, though the idea of extended attributes is worth exploring. Again, the sensible way might be to allow more than one possibility through options.
One request has been for Atom images, and I am sure this is possible. However, I have never used an Atom, even in emulation, and I would need to familiarize myself with it so that I could try the results out - I wouldn't trust my work to be bug-free without testing!!
The program currently rejects image files that don't match fairly accurately one of the formats it knows. I have thought about allowing the program to attempt to interpret files that don't quite match. (Such might arise from corrupted disks, for example, or slightly different formats.) This needs care, to make sure such images cannot cause a program crash.

A couple of things I am not going to worry about for the moment:

I am going to have to leave drag-and-drop for the time being, unless I make a final decision about .inf files that is compatible with it.
However demonic they may be , I have never had any problem with spaces in Windows filenames (or not recently - they may have been a bit unreliable in Windows 95/98/Me - but I am not intending to cope with those in any case)

None of these are going to get done overnight, especially not over Easter, but I will devote some time to them when I can.

David

geraldholdsworth · Post by **geraldholdsworth** » Fri Mar 30, 2018 7:49 pm

yellowpig wrote:I mentioned in a recent thread that I have been working on a (Windows) program to handle BBC disk images. It is now at a stage where others might like to try it out.

Wow - what's that now? Three different utilities for Windows all being developed simultaneously.
I suppose at least this one can write files to images...I keep putting that bit of the code off! And mine is just a Pascal Class, as opposed to a proper Windows application.

vanekp · Post by **vanekp** » Sat Mar 31, 2018 6:49 pm

it won't open my ADFS image.
It comes up with this message

: BeebImage.png (4.36 KiB) Viewed 7747 times

Yet it works fine in BeebEm and can open it with ADFS Explorer.
scsi0.dat file of 38Mb actual disc size it original came off was 295,349,760 bytes
Here it is open in ADFS Explorer.

yellowpig · Post by **yellowpig** » Sun Apr 01, 2018 12:04 am

vanekp wrote:it won't open my ADFS image.
It comes up with this message ...

Can you possibly send me a copy of the offending image file, perhaps attached to a PM? I can then try to find the problem.

David

geraldholdsworth · Post by **geraldholdsworth** » Sun Apr 01, 2018 1:11 pm

If it's the files from BeebEm, mine won't open them either. Annoyingly, it did - but I made a change which somehow affected it.
From my perspective, the header checksums (at 0x0FF and 0x1FF) don't match what is calculated (either one or the other is off by 1). The same is true for the *.adl files supplied with BeebEm.

yellowpig · Post by **yellowpig** » Mon Apr 02, 2018 9:04 am

This may be a disk size issue.

On an ADFS disk, the three bytes at &FC to &FE normally contain the number of sectors on the disk, and for floppies this should normally be &280 (for small disks), &500 (medium) or &A00 (large). On one of the disks distributed with BeebEm (the one called L3FS-ISW.adl) the number in these bytes is &400. This causes Beeb Image to deduce that the file is corrupted, and reject it.

I clearly need to rewrite things a bit so that the tests on file consistency are a bit less stringent.

I will have a go at this over the next few days.

David

Ottly · Post by **Ottly** » Tue Apr 03, 2018 7:32 am

Firstly thank you for a great looking and easy to use disk image editor.

Was wondering if you are planning on implementing support for the larger ADFS disk images used by the Archimedes/Risc PC (1.6mb etc..)?

yellowpig · Post by **yellowpig** » Tue Apr 03, 2018 12:49 pm

Ottly wrote:Was wondering if you are planning on implementing support for the larger ADFS disk images used by the Archimedes/Risc PC (1.6mb etc..)?

I am happy to consider this, but it will take some time. I will need to know in detail what the format of such images is. I know this is available in threads on this forum, or web pages maintained by forum members, but I will need to find the information and study it - some people have recently suggested that it is not the simplest format to interpret. I would then need to test the results. I have never had access to an Arc / Risc machine, or indeed ever tried one out on an emulator. I will have to play around with one for a bit to get used to exactly how it operates.

David

geraldholdsworth · Post by **geraldholdsworth** » Tue Apr 03, 2018 2:11 pm

yellowpig wrote:This may be a disk size issue.

I ignore the disc size values, as I want to handle hard discs also. Only time I take any notice is to ensure it is >0bytes (if the first 512 bytes are all zeros, the checksums will pass - this means that a Commodore 64 disc image can get mis-IDed as an ADFS).

I found that the problem was with my code - I was adding an extra carry. I started from byte 0 of the sector and accumulated everything up to byte 254, then added the carries. However, I found I needed to start at byte 254, add the carry (then clear it), before adding the byte. Then repeating this down to byte 0.

geraldholdsworth · Post by **geraldholdsworth** » Tue Apr 03, 2018 2:14 pm

yellowpig wrote:I will need to know in detail what the format of such images is. I know this is available in threads on this forum, or web pages maintained by forum members, but I will need to find the information and study it - some people have recently suggested that it is not the simplest format to interpret.

That would be me that has written a guide:
http://www.geraldholdsworth.co.uk/DiscI ... cImage.pdf
and I've tried to make it simple to understand.

If you need a hand, let me know (my email is in the PDF). If you want to take a look at my code (which is in Pascal/Delphi):
http://www.geraldholdsworth.co.uk/code. ... =DiscImage
(still being written, I might add!!)

Cheers,

Gerald.

yellowpig · Post by **yellowpig** » Tue Apr 03, 2018 3:33 pm

geraldholdsworth wrote:
yellowpig wrote:This may be a disk size issue.
I ignore the disc size values, as I want to handle hard discs also. Only time I take any notice is to ensure it is >0bytes (if the first 512 bytes are all zeros, the checksums will pass - this means that a Commodore 64 disc image can get mis-IDed as an ADFS).

I have assumed that anything over 1Mb is a hard disk. Anything less I have assumed is a floppy, and that it must match one of the standard sizes. I am going to take away this latter restriction.

I found that the problem was with my code - I was adding an extra carry. I started from byte 0 of the sector and accumulated everything up to byte 254, then added the carries. However, I found I needed to start at byte 254, add the carry (then clear it), before adding the byte. Then repeating this down to byte 0.

I am not currently botherig to look at the checksums, but one has to get them correct for writing images. That missing carry bit can lead to errors if you are not careful.

yellowpig · Post by **yellowpig** » Tue Apr 03, 2018 3:35 pm

geraldholdsworth wrote:
yellowpig wrote:I will need to know in detail what the format of such images is. I know this is available in threads on this forum, or web pages maintained by forum members, but I will need to find the information and study it - some people have recently suggested that it is not the simplest format to interpret.
That would be me that has written a guide:
http://www.geraldholdsworth.co.uk/DiscI ... cImage.pdf
and I've tried to make it simple to understand.

If you need a hand, let me know (my email is in the PDF). If you want to take a look at my code (which is in Pascal/Delphi):
http://www.geraldholdsworth.co.uk/code. ... =DiscImage
(still being written, I might add!!)

Thanks. All that looks very helpful.

David

jgharston · Post by **jgharston** » Fri Apr 06, 2018 4:48 pm

A quick dashing visit.

You do drag'n'drop and checking for .inf sidecar files like this. This is BBC BASIC, it should be simple enough to translate to your language of choice. See link for source and demo pre-compiled Windows binary.

Code: Select all

      REM > DropFiles
      REM Demo drag'n'drop in Windows
      REM R.T.Russell with amendements

      WM_DROPFILES = &233
      *SYS 1

      MaxDroppedFiles% = 100
      DIM DroppedFile$(MaxDroppedFiles%-1), DroppedAt{x%,y%}
      Dropped% = 0

      ON SYS PROCsys(@msg%, @wparam%, @lparam%) : RETURN
      SYS "DragAcceptFiles", @hwnd%, 1

      REPEAT
        WAIT 1
        IF Dropped% THEN
          PRINT "Number of objects dropped: ";Dropped%
          PRINT "Objects dropped at x=";DroppedAt.x%;", y=";DroppedAt.y%
          FOR I% = 0 TO Dropped%-1
            IF I% >= MaxDroppedFiles% THEN EXIT FOR
            PRINT "Object ";I%;": ";
            SYS "GetFileAttributes", DroppedFile$(I%) TO sh%
            IF sh% AND 16 THEN PRINT"Dir. "; ELSE PRINT"File ";
            PRINT DroppedFile$(I%)
            ch%=OPENIN(DroppedFile$(I%)+".inf")
            IF ch% THEN
              LD$="":EX$="":AT$=""
              A$=GET$#ch%:CLOSE#ch%
              A$=MID$(A$,INSTR(A$," ")+1)
              WHILE LEFT$(A$,1)=" ":A$=MID$(A$,2):ENDWHILE
              A%=INSTR(A$+" "," "):LD$=LEFT$(A$,A%-1):A$=MID$(A$,A%+1)
              WHILE LEFT$(A$,1)=" ":A$=MID$(A$,2):ENDWHILE
              A%=INSTR(A$+" "," "):EX$=LEFT$(A$,A%-1):A$=MID$(A$,A%+1)
              WHILE LEFT$(A$,1)=" ":A$=MID$(A$,2):ENDWHILE
              A%=INSTR(A$+" "," "):SZ$=LEFT$(A$,A%-1):A$=MID$(A$,A%+1)
              WHILE LEFT$(A$,1)=" ":A$=MID$(A$,2):ENDWHILE
              A%=INSTR(A$+" "," "):AT$=LEFT$(A$,A%-1):A$=MID$(A$,A%+1)
              IF LEFT$(AT$,1)="L":A$="08"
              PRINT"BBC info: ";LD$;" ";EX$;" ";SZ$;" ";AT$
            ENDIF
          NEXT I%
          Dropped% = 0
        ENDIF
      UNTIL FALSE
      END

      DEFPROCsys(M%,W%,L%)
      CASE M% OF
        WHEN WM_DROPFILES:
          LOCAL B%, I%
          DIM B% LOCAL 260
          SYS "DragQueryFile", W%, -1, 0, 0 TO Dropped%
          IF Dropped% <> 0 THEN
            FOR I% = 0 TO Dropped%-1
              IF I% >= MaxDroppedFiles% THEN EXIT FOR
              SYS "DragQueryFile", W%, I%, B%, 260
              DroppedFile$(I%) = $$B%
            NEXT I%
          ENDIF
          SYS "DragQueryPoint", W%, DroppedAt{}
          SYS "DragFinish", W%
      ENDCASE
      ENDPROC

jgharston · Post by **jgharston** » Fri Apr 06, 2018 4:54 pm

yellowpig wrote:[*]One request has been for Atom images, and I am sure this is possible. However, I have never used an Atom, even in emulation, and I would need to familiarize myself with it so that I could try the results out - I wouldn't trust my work to be bug-free without testing!!

The only difference with Atom DOS is that the default directory is " " instead of "$", so just ensure that extracting from directory " " creates "filename" and not " .filename". There are plenty of Atom DOS disk images floating around for testing, eg: SBASIC.ssd, ABASIC.ssd.

yellowpig · Post by **yellowpig** » Sat Apr 07, 2018 11:55 am

I have made a few minor revisions to the program. In particular:

You can now use the character translation JGH wrote about:
Also, remember to translate between BBC filename characters and WinDOS characters:
# <-> ?
. <-> /
$ <-> <
^ <-> >
& <-> +
@ <-> =
% <-> ;
And special case, as it's nonreversable: WinDOS SPC -> BBC _
I have made this an option, because I think there is also sense in the original one I used (which copies the Master 512's MOVE.EXE utility)

The program will now accept more not-quite-standard image files. There is an option for whether these are flagged up on load.

I have added buttons for Cut Files, Copy Files and Paste Files. (I find I am using these functions frequently, and it is easier if they are more accessible.)

I have added some markers in the Help pages to make them a bit simpler to navigate.

It is going to take a bit more work to implement the one-inf-per-file (or other) method of storing BBC meta-data. Exactly how I do that will affect whether or not I implement drag-and-drop (which will also take some work - thanks JGH for ideas of how to do it).

As a reminder, the program is at: http://www.cowsarenotpurple.co.uk/beeb-image.html

David

simonm · Post by **simonm** » Sat Apr 07, 2018 5:12 pm

This is really great David. Given that I was considering writing such a tool from scratch, you've accelerated the process significantly.
You mentioned you'd be open to sharing the source, which would be really fantastic for me just now as I'm particularly interested in finding a way to get my A5000 files off a CF image file.
I (and I'm sure many others) would also be happy to contribute in any way to help make this our community disk management tool if you are into that idea - as none of the other options for acorn file management are free or open source.
In case you dont have any preference at the moment for where/how to share the project, I would strongly recommend GitHub - at the very least it's awesome for tracking issues (such as bugs, improvements or features), and a lot of the Stardot community are already active on there.
Let me know if you aren't already familiar with Git/GitHub and I'd be happy to give you some starter tips.

geraldholdsworth · Post by **geraldholdsworth** » Sun Apr 08, 2018 10:32 am

simonm wrote:I'm particularly interested in finding a way to get my A5000 files off a CF image file.

Have you tried my Image Reader (linked to in this thread, above) - it can read New Map ADFS, which I'm assuming is the format your CF image file is in.
My code is somewhat behind David's in that it can only read from images, not write back to them (writing back is on the cards). But, in the same respects, my can also read more different image formats.
The main aim of my code was just a code library, written in conjunction with Jasper Renow-Clarke with his floppy controller board on the Pi, but with the target of adding it to my Repton Map Display application - I didn't intend on writing a disc image reader...that was just a demo

yellowpig · Post by **yellowpig** » Mon Apr 09, 2018 7:16 pm

Just spotted a bug with saving double-sided DFS images. (If the image of the second side of the disk is longer than the first side, then it was possible for the end of the last file on the second side to be corrupted.)

I have now corrected the problem, and put the replacement version on my website at: http://www.cowsarenotpurple.co.uk/beeb-image.html. Can I suggest that anyone who wants to use the program should download the new one.

My apologioes for this.

David

jgharston · Post by **jgharston** » Tue Apr 10, 2018 4:42 pm

I haven't had chance to get any programming stuff done for a bit, but yesterday found time to check UnImg and fix a couple of bugs and build some test environments. I don't have my source code with me, so it's patched together a bit, but any code that extracts files from a disk image should match its functionality (Edit: and consequently, only the Windows version on my site is updated). (There's an issue where if the source has filenames that are impossible to create without a Bad filename error, trying to extract then will also create a Bad filename error.)

I've also uploaded a test file with a set of test disk image files and what extracting from them should create on a non-Acorn platform.

I'd completely forgotten I'd typed up information on storing Acorn metadata on other platforms, which includes filename translation:
* Metadata
* INFfile

Note that MkImg still has an odd bug in the filename translation, but I don't have my notes here to remind me exactly how to replicate it.

Wouter Scholten · Post by **Wouter Scholten** » Mon Apr 16, 2018 10:31 pm

crj wrote:It's actually pretty unappealing that the .INF technique doesn't cope with spaces in filenames. Also, that the file has a .INF extension but isn't in INF format. Also, that finding a file by name is O(n) on the number of files in the directory.

I mean yes, if it's become a de facto standard it has to be supported for interface purposes, but I'm unconvinced it was ever a sound engineering choice, let alone the best choice now.

Oh please give us all a break with your 'sound engineering practice'. Anyone who uses C, C++, or other languages complied to those languages such as Eiffel already gives up any right to talk about proper engineering practice, due to no integer overflow checks etc., and in case of EIffel this is despite that being the language having most features for actual engineering practices... (and if you are talking actual engineering practices, have you ever made programs that verified their own code? I have, I know what real engineering is about but I also know when good-enough is good-enough, and when I did all myself and got just about no feedback from others, then I will do what suits me and gets the job done quickly. Anyone who's not autistic will understand there is always tradeoff between perfection (which in reality doesn't exist) and practicality in a give situation).

Many years ago someone else criticised (I think on this site) some utilities that we (Robert Schmidt and I) made or worked on and Robert got quite annoyed about it as that person gave a quite autistic view, i.e. limited understanding on only some issues, and not properly understanding anything surrounding how, when and why they were made and what we at that time had to deal with and how to get things working, and also which emulators were used (e.g. Xbeeb with its catalogue which influenced the decision to use separate file attributes as a text file, and using separate attributes was needed in my view for clean access to files. You may like something else, fine, this was my choice. It could definitely be improved, esp. remove all conditional stuff, which makes decoding harder. And you can put filenames in "" so e.g. a improvement could be something like this, which is invalid as regular inf, and thus utilities not updated for this will/should give an error message, but bbcim and other utilities could be changed to incorporate this in the next version and then do the right thing with it:

INF2 TAPE 3 "xxx" loadadresss execaddress Locked
INF2 DFS 5 "xxxxx" loadadresss execaddress Locked
INF2 NFS 2 "xx" loadadresss execaddress fileattributes

where the solution for filenames is then xxx = any bytes, number before the " is number of bytes. Another option would be similar to what DFS does, with a &0D to denote end after which comes the " though that would be unclean in terms of viewing a neat text file... There are other options.

Also note that e.g. for the Mac I never got any feedback for bbcim, and Risc OS was something we didn't use so we just had to guess some things and see what happens as we were not autistic enough to go do an enumeration of file systems that might be used with a BBC emulator.

And the CRC was because of all the problems I had transferring files esp. with MS DOS/Windoze and file integrity there even when doing nothing to those files (I remember a check disk which nuked some of my files of Duke Nukem 3D. Years later I was only using FreeBSD for anything serious as I still do now (no windows), and then I had other issues with files getting corrupted, in case of internal copying from SATA UFS disk to SATA UFS disk, caused by a disk controller flipping some bits every few megabytes in this case (not IDE <-> SATA, only SATA<->SATA). I experienced that e.g. with a Asus A7V600, and another system too, only with the advent of ZFS have things got to where I wanted them to be in 1995, which is CRCs for all files...).

I would remove the CRC too now, as I do CRC checking for all files separately for anything that's important.

The O(n) is not a problem for a non-native file system. I had other other ideas for the TAPE NEXT too, these are all things that could be done in various ways, send me some suggestions and I will include it into bbcim for a new version to address any issues that there are.

crj · Post by **crj** » Tue Apr 17, 2018 3:49 am

Wouter Scholten wrote:Anyone who uses C, C++, or other languages complied to those languages such as Eiffel already gives up any right to talk about proper engineering practice [...] Anyone who's not autistic will understand there is always tradeoff between perfection (which in reality doesn't exist) and practicality in a give situation).

So... I'm not allowed to talk about good engineering practices because C++ is one of the languages I use, but you think I don't understand tradeoffs? Hmm.

e.g. Xbeeb with its catalogue which influenced the decision to use separate file attributes as a text file, and using separate attributes was needed in my view for clean access to files

Even if it made sense to put file attributes in a separate text file, it makes no sense to give that file a .INF extension, when .INF has been the extension for a completely different file format that's existed since at least 1990. Worse, Windows .INF files are frequently paired with files that have the same basename plus other extensions (I just looked at a specimen machine and found that happened in hundreds of cases.)

However, it doesn't make sense to put file attributes in a separate text file with the same name as the main file plus an extension. The only use that has is mapping from host filename to attributes, but that's never what you want to do. Alternatives include:

Put all the attributes in one file per directory
Put all the attributes in one file per hierarchy
Put the attributes for each Acorn file in a separate file, with a random name.
Put the attributes for each Acorn file in a separate file, with a name which canonicalises the Acorn filename to the host OS's collation
Put the attributes for each file in a separate file with the same name in a subdirectory. (Like Apple's __MACOSX . Note that this has the advantage that you can definitely create a file in the subdirectory with the same name as the one in the main directory, whereas you can't always add a suffix to a filename)
Put the attributes for each Acorn file in a separate file with either random or canonicalised filename, in a subdirectory
Put the attributes within the file itself (like the MacBinary format)
Keep the Acorn files and their attributes bundled up in an archive file (tar/zip/Spark/whatever.)
Keep the Acorn files and their attributes in an Acorn filesystem image
Embed the attributes for each Acorn file in the host filename
Embed the attributes for each Acorn file in the name of a separate dummy filesystem object (Many "lockfiles" use this trick.)
Use the host filesystem's extended attributes support

The last of those has only been widely possible for half a decade or so, the two before that only for a couple of decades, but the others have been possible since forever.

And you can put filenames in ""

Changing the format so filenames are quoted may get rid of the problem of spaces in filenames, but immediately replaces it with the problem of quotation marks in filenames.

It could definitely be improved, esp. remove all conditional stuff, which makes decoding harder

Alternatively, using a key-value format instead of a conditional one would allow for more reliable interpretation, omitting data that's not available, adding more fields in future, etc.

sweh · Post by **sweh** » Wed Apr 18, 2018 3:02 am

Wouter Scholten wrote:And you can put filenames in "" so e.g. a improvement could be something like this, which is invalid as regular inf, and thus utilities not updated for this will/should give an error message, but bbcim and other utilities could be changed to incorporate this in the next version and then do the right thing with it:

INF2 TAPE 3 "xxx" loadadresss execaddress Locked
INF2 DFS 5 "xxxxx" loadadresss execaddress Locked
INF2 NFS 2 "xx" loadadresss execaddress fileattributes

where the solution for filenames is then xxx = any bytes, number before the " is number of bytes. Another option would be similar to what DFS does, with a &0D to denote end after which comes the " though that would be unclean in terms of viewing a neat text file... There are other options.

I wonder if we can create something that's backwards compatible. I wonder how many tools currently read the _second_ line of the INF file? So we could have

Code: Select all

FOO_BAR load exec Locked
V2
NAME:FOO BAR

v2 aware code can look for the second line and if it's V2 then read the 3rd line for NAME: then use that as the filename. Existing code will use the FOO_BAR name instead. Potentially this tagged format would allow for future enhancements as well. ("SOURCE:TAPE"?)

Pernod · Post by **Pernod** » Wed Apr 18, 2018 11:24 am

I just loaded up a SSD containing four files with the purpose of simply changing the Boot Option from 0 to 3. When I saved this I expected only a single byte to be changed in the image, but no. It had re-ordered all the files in the image. If no files are being added or removed from the image then I'd prefer it didn't effectively re-create the image from scratch.

jgharston · Post by **jgharston** » Wed Apr 18, 2018 2:53 pm

crj wrote:Even if it made sense to put file attributes in a separate text file, it makes no sense to give that file a .INF extension, when .INF has been the extension for a completely different file format that's existed since at least 1990. Worse, Windows .INF files are frequently paired with files that have the same basename plus other extensions (I just looked at a specimen machine and found that happened in hundreds of cases.)
However, it doesn't make sense to put file attributes in a separate text file with the same name as the main file plus an extension

Even if INF files don't make sense, either now or then, it's been around for more 25 years and any system that doesn't support them will have the failing that it doesn't support them. It's not the system I'd have invented 25 years ago, but that was the system invented 25 years ago and loads and loads of programs have been written to expect and use them.

None of that means you shouldn't invent a different system it's just that all the existing software that uses the pre-existing system will be unable to input the new system and will output stuff that the new system can't use.

jgharston · Post by **jgharston** » Wed Apr 18, 2018 2:56 pm

sweh wrote:I wonder if we can create something that's backwards compatible. I wonder how many tools currently read the _second_ line of the INF file? So we could have
Code: Select all
FOO_BAR load exec Locked
V2
NAME:FOO BAR
v2 aware code can look for the second line and if it's V2 then read the 3rd line for NAME: then use that as the filename. Existing code will use the FOO_BAR name instead. Potentially this tagged format would allow for future enhancements as well. ("SOURCE:TAPE"?)

Wouldn't even need to look for V2, just look for the existance of second and further lines.

jgharston · Post by **jgharston** » Wed Apr 18, 2018 3:04 pm

crj wrote:Alternatives include:

Any alternatives must start with "what happens with existing systems". So, going back 25 years, "what happens when I use an Acorn system to copy a file from an Acorn filesystem to a DOS disk?" Which, in terms of filenames is: the filename is as close to identical as possible. So, dragging HELLO from ADFS::HARDDISK4 to DOSFS::0 circa 1990, or using RdAcorn circa 1987, or ReadDFS circa 1985, results in a file called HELLO on the DOS disk and visible from DOS as a file called HELLO and loadable from programs running on DOS by using the filename HELLO.

crj · Post by **crj** » Wed Apr 18, 2018 4:07 pm

sweh wrote:I wonder if we can create something that's backwards compatible. I wonder how many tools currently read the _second_ line of the INF file?

OK. Here's the first difficulty we encounter with that idea: what is the "second line" of an INF file? Specifically, does the file use Acorn line endings, host line endings or network line endings? Is it defined whether INF files are text or binary, and therefore how they shall be treated when moved between systems? The safest option would be to define that either CR or LF denoted a line ending and that all whitespace-only lines were ignored in looking for V2 data.

However, I feel a better way to retain backward compatabilty would be to implement some more suitable alternative that's largely independent of .INF files. There wouldn't be anything stopping software creating both that alternative metadata and a .INF file.

The alternative could be chosen to avoid the clutter that .INF files cause. In that case, if used along with .INF files it would add little extra clutter, and if used without .INF files you'd enjoy a clutter-free filesystem. If you define an extension to .INF files, you're unnecessarily perpetuating several of their disadvantages.

One nice tweak, though, would be to include in any alternative metadata an indication of whether a .INF file was created and, if so, under what name. That would allow software manipulating the alternative to know whether or not it "owned" any .INF files discovered in the filesystem (i.e. whether it should hide them from view and/or keep them up to date with changes).

stardot.org.uk

New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor

Re: New Disk Image Editor