New Disk Image Editor
Re: New Disk Image Editor
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.
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.
Re: New Disk Image Editor
^^ 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.
Re: New Disk Image Editor
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
Re: New Disk Image Editor
There have been a number of suggestions in these posts, and I will try to implement some of them:
David
- 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.
- 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)
David
- geraldholdsworth
- Posts: 1406
- Joined: Tue Nov 04, 2014 9:42 pm
- Location: Inverness, Scotland
- Contact:
Re: New Disk Image Editor
Wow - what's that now? Three different utilities for Windows all being developed simultaneously.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.
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.
Gerald Holdsworth, CTS-D
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Re: New Disk Image Editor
it won't open my ADFS image.
It comes up with this message 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.
It comes up with this message 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.
Re: New Disk Image Editor
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.vanekp wrote:it won't open my ADFS image.
It comes up with this message ...
David
- geraldholdsworth
- Posts: 1406
- Joined: Tue Nov 04, 2014 9:42 pm
- Location: Inverness, Scotland
- Contact:
Re: New Disk Image Editor
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.
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.
Gerald Holdsworth, CTS-D
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Re: New Disk Image Editor
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
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
Re: New Disk Image Editor
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..)?
Was wondering if you are planning on implementing support for the larger ADFS disk images used by the Archimedes/Risc PC (1.6mb etc..)?
Re: New Disk Image Editor
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.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..)?
David
- geraldholdsworth
- Posts: 1406
- Joined: Tue Nov 04, 2014 9:42 pm
- Location: Inverness, Scotland
- Contact:
Re: New Disk Image Editor
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).yellowpig wrote:This may be a disk size issue.
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.
Gerald Holdsworth, CTS-D
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
- geraldholdsworth
- Posts: 1406
- Joined: Tue Nov 04, 2014 9:42 pm
- Location: Inverness, Scotland
- Contact:
Re: New Disk Image Editor
That would be me that has written a guide: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.
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.
Gerald Holdsworth, CTS-D
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Re: New Disk Image Editor
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.geraldholdsworth wrote: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).yellowpig wrote:This may be a disk size issue.
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.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.
Re: New Disk Image Editor
Thanks. All that looks very helpful.geraldholdsworth wrote:That would be me that has written a guide: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.
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!!)
David
Re: New Disk Image Editor
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.
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
Last edited by jgharston on Tue Apr 10, 2018 4:44 pm, edited 1 time in total.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
Re: New Disk Image Editor
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 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!!
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
Re: New Disk Image Editor
I have made a few minor revisions to the program. In particular:
As a reminder, the program is at: http://www.cowsarenotpurple.co.uk/beeb-image.html
David
- You can now use the character translation JGH wrote about:
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)Also, remember to translate between BBC filename characters and WinDOS characters:
# <-> ?
. <-> /
$ <-> <
^ <-> >
& <-> +
@ <-> =
% <-> ;
And special case, as it's nonreversable: WinDOS SPC -> BBC _
- 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.
As a reminder, the program is at: http://www.cowsarenotpurple.co.uk/beeb-image.html
David
Re: New Disk Image Editor
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.
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
- Posts: 1406
- Joined: Tue Nov 04, 2014 9:42 pm
- Location: Inverness, Scotland
- Contact:
Re: New Disk Image Editor
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.simonm wrote:I'm particularly interested in finding a way to get my A5000 files off a CF image file.
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
Gerald Holdsworth, CTS-D
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Extron Authorised Programmer
https://www.geraldholdsworth.co.uk
https://www.reptonresourcepage.co.uk
Twitter @radiogezza
Re: New Disk Image Editor
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
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
Re: New Disk Image Editor
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.
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.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
- Wouter Scholten
- Posts: 235
- Joined: Wed May 02, 2001 11:14 pm
- Location: NL
- Contact:
Re: New Disk Image Editor
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.
Re: New Disk Image Editor
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.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).
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.)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
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
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.And you can put filenames in ""
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.It could definitely be improved, esp. remove all conditional stuff, which makes decoding harder
Re: New Disk Image Editor
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 haveWouter 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.
Code: Select all
FOO_BAR load exec Locked
V2
NAME:FOO BAR
Rgds
Stephen
Stephen
Re: New Disk Image Editor
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.
- Nigel
BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
BBC Model B: ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, BeebZIF, etc.
Re: New Disk Image Editor
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.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
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.
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
Re: New Disk Image Editor
Wouldn't even need to look for V2, just look for the existance of second and further lines.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 havev2 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"?)Code: Select all
FOO_BAR load exec Locked V2 NAME:FOO BAR
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
Re: New Disk Image Editor
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 wrote:Alternatives include:
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
Re: New Disk Image Editor
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.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?
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).