Closed dcutugno closed 3 months ago
Some modification i did that seems to works a314fs.c: https://pastebin.com/jYLzH56Z Any other way to better show and simplify to paste here the code changes?
This solution implies a fixed block with a limit to about 1TB disks. Can be implemnted also a dynamic block adjustment logic that stops at 0x7FFFFFFF blocks (the maximum positive 32-bit integer) to ensure compatibility with AmigaOS functions that might use signed integers. This dynamic implementation should allow to represent larger disks more accurately while still maintaining compatibility with AmigaOS. For example, with this approach could represent a disk up to about 16 TB (0x7FFFFFFF * 8192 bytes) without issues.
"Any other way to better show and simplify to paste here the code changes?"
If you make a new branch in your repo (your fork of the a314 repo) then you can do a commit with your changes there and link to the commit in your comment, then it should be clear what changes you are referring to.
If you do this (make a branch and add a commit with your changes) then we can have a look.
If you go to the link you posted you'll see that there are many lines marked as changed, where only the indentation has changed. If you keep the same indentation as in the original code then it will be a lot easier to see what the actual changes are.
i see, vscode didn't show me them on changes view...
It seems your code is addressing multiple unrelated issues. The issue that is described in this GitHub issue is that the info
tool reports "Unreadable disk". This seems to be related to the returned dl_DiskType, which is ID_314_DISK.
Then your code is altering something related to the reported number of blocks. This seems unrelated to the "Unreadable disk" issue. It would be good if you could update your commit to only deal with the unreadable disk issue. See the "Smaller is better" guideline on on this page: https://github.com/jessesquires/.github/blob/main/CONTRIBUTING.md#repeat-submitting-pull-requests.
When using old WB versions the INFO command shouldn't report Unreadable Disk, maybe is related on how ID_DOS_DISK type is reported. Here some references: On SMBFS implementation https://github.com/obarthel/amiga-smbfs/blob/8fd5546afdd6390e962b31f0e114d126144c3bc7/source_code/main.c#L7155C24-L7155C35
On FAT95:
move.l #ID_DOS,ID_DiskType(a0) ;intentionally incorrect for Workbench.. ;..and info shell tool