TLDR: >>>> https://github.com/deadw00d/AROS/labels/IBOTM <<<<

Hello,

I have an idea for a small activity aside from my general AROS work. It will allow community to steer fixing of bugs that irritate them

EDIT: adjusted rules 20231023

General rules are simple:

1) Bugs are selected from bugs reported on bug tracker
2) There is a poll made and community selects one bug from suggested bugs
3) I fix the bug.
4) Delay(1 month); Go To 1;

The initial list of bugs will be related to ABIv0 i386 or ABIv11 x86_64. In effect bugs specific to m68k AROS or any other AROS flavor won't be added to poll options. Bugs can be in either AROS core system or in Contrib package. Bugs need to be reproducible on clean system releases, so bugs visible only on distributions won't be included.

If you are interested in participating, check the poll above,read through selected bugs
>>>> https://github.com/deadw00d/AROS/labels/IBOTM <<<<
and then vote. I'll close voting on Sunday 29th. If you have any additional questions, let me know.

Based on the feedback I'll see how the idea catches on and how to continue with it.

That is a very nice idea and generous gesture deadwood.

I have but one question for now: What do you consider being a bug ?

By that I mean with regards to behavioural differences, e.g. what is the base system that certain behaviour should be compared against ? The generic Amiga Workbench 3.x ? (and what does 3.x means these days ?).

How about ported software, does that count as well ? and should the behaviour of ports be compared against the general behaviour as was intended for the original host target (or generalized when multiple targets apply) ?

Hoping that having this cleared up makes things easier for you.

I guess the most obvious case is: you do something and get a crash. With regards to functionality, yes I'd say that 3.1 is the reference for system and m68k version of software in case of ported software. At the end of the day, I'll review bug reported here and if there is any question whether something is a bug or not, we'll discuss and decide here, so @everyone go ahead and submit your picks and we'll see where we'll end up.

This seems like a fun way to get user interaction & feedback. It's also a good way to fix those irritating bugs!

Some of these only require small fixes so they aren't really top priority. But they certainly are very irritating when they don't work right.

I have two irritating bug reports so far. They have been bothering me for a few years but I didn't bother to try to fix them. I'll fill out the official bug report as well but I'd like to describe them to see if they qualify as "bugs". 🙂

The first is when we attach a floppy or Zip drive, or whatever drive then insert a PC formatted disk whether it's FAT12 or FAT16. When I use Disk Info in Wanderer it reports the filesystem as "OFS". It's not OFS because that's only for Amiga! It should report the true filesystem as FAT12 or FAT16 not OFS for everything. Even just FAT for both would be fine. Also there is an ugly " lazy m" icon next to the OFS text that is really irritating. It serves no special purpose & should be removed.

The second irritating bug, or is that the third? Anyhow, again when using DiskInfo for a mounted PC formatted disk it reports the full disk size as disk capacity. That's incorrect. It should calculate filesystem overhead then subtract that from total size to get the capacity. It gets the correct used space so it must be using the correct method to read the File Allocation Table. But fat-handler isn't using the formula to calculate filesystem overhead. Interesting that afs-handler gets the correct capacity for ADF .

That's it for now.

Ok, for the first two issues I created a bug report here:

https://github.co...issues/105

For the third topic, I think this is how it should be. The capacity refers as far as I can see to capacity of medium, not total available size of filesystem on medium. See comparison of an ADF attached to WB 3.1 and Wanderer as well as a PC 1.44 disk image.

After some more thinking I decided to alter the approach a bit. You can continue to report bugs as you stumble on them and I will add them to the bug-tracker in a separate "cycle".

As for this topic, I think it makes more sense to select already existing and reported bugs. For this first iteration, I selected 10 bugs, you can see them here:

>>>>>>> https://github.co...bels/IBOTM <<<<<<<<<

See if you would like to have any of them solved and then vote in poll!

deadwood

In the image you posted for the blank ADF the capacity is 1758 blocks which is total blocks - 2. That's correct because total sectors are 1760 (512 bytes per sector) = 901,120 bytes (880k). But the block size for ADF is reported as 488 bytes because system data is stored in each block. There are two used blocks for an ADF that is formatted leaving 1758 blocks of capacity

For a PC formatted High Density Disk there are 2880 sectors (512 bytes each) because 80*2*18 is 2880. Just like total size for ADF is 901,120 the total size for PC disk is 1,474,560 (1440kb). But just like the 2 used blocks for ADF there are 33 sectors used for the filesystem data which leaves 2847 data sectors (1,457,664 bytes). So the true disk capacity is only 1423.5kb not 1440kb. AROS reports used space for PC disks correctly but the disk capacity is not 1,474,560.

In the screenshot notice the difference. Free space is correct. Because Disk Capacity is 1423.5kb not 1440kb used space is 440kb (1423.5-983=440.5) not 457kb (1440-983=457). And F.Sys = FAT not OFS.

deadwood

Bug item no. 7 for Wanderer not able to delete a single item should have been resolved in ABIv1 some time ago.

For the FAT Disk Used Space error I reported earlier I realize now the mistake. I'm looking at DiskInfo on Icaros Desktop for Magellan. You are probably using DiskInfo for Wanderer which seems correct as far as the calculations. Magellan's DiskInfo has a Used Space error.

Indeed #105 covers only the fact that wrong file system name is presented and the tiny diskette icon beside it.

The topic of whether capacity and used space should include file system data in its calculation is another matter and should be another report, however I don't know if this is really a bug. The question is whether there is consistency across all file systems on how they report this and only fat-handler is wrong or some file systems add system data to capacity and some not. This would have to be investigated before deciding that fat-handler does this thing wrong.

I understand that Windows does it differently, but Windows is not a reference I'd use - rather other OS 3.1, OS 4.0 and MorphOS filesystem would be a reference in my opinion.

All the bugs mentioned in the link are important, I would give as 'irritable' those concerning the operating system, where we often collide on a daily basis, order of importance I think there are:

1) Wanderer: properly run tools with CLI tooltype

2) Errors while moving files to Storage or WBStartup

3) Wanderer: single icon without the associated file cannot be deleted

4) Rename issues with fat-handler

5) Regression: Volume Information Window

No one mentioned Odyssey I'm not saying a massive update but maybe some tweaking, or noticed that I can no longer use my yahoo email services it was still accessible but now it doesn't

Odyssey not working isn't a bug. That's a complete re-write. It's a lot more involved than a simple fix for a single issue.

there is also to consider the TCP stack, I can take advantage of a cloud service, but the file transfer is very slow, it should be reviewed

I get that you got all excited by deadwood's proposal (that is good !) but TCP stack being slow is also not a bug and requires quite a bit more than just some fixing.

The assignment/rules from deadwood is/are simple: Pick one from the list that deadwood posted. If you have other bugs then report these bugs so that they become part of the bugtracker. That allows deadwood to review the bugreport(s) and decide whether or not he want to address that in another upcoming month.

There is no gain (for us and deadwood) to keep suggesting improvements inside this thread. I have a ton of suggestions for improvements but I am also realistic in that deadwood is but one person and that he wants to focus (or at least tries) on single simple bugs that already exist (and not so much improving on things that are already working).

But ofc. that is just 2 cents from what I understood that deadwood wants to commit to (if he decides to commit to this at all because imho that is still not set in stone yet either (and that is ok because it is his time/schedule) ).

ok Magorium many thanks

Honestly this version of Odyssey was enough for me, I'm a retro user, of course sometimes I have to start Windows for some sites, one in particular and now to read and write the email, for this I wanted to understand if it could be retouched instead of rewriting everything from scratch with a new webkit engine

Ok, the voting is now closed the we have a winner!

#64 (Wanderer: properly run tools with CLI tooltype)

I'll start looking into details of this problem and then work on solution.

@deadwood

The bug links on "https://github.com/deadw00d/AROS/labels/IBOTM" point to the old aros-exec, so they no longer work.
To fix this, simply replace the suffix "ae.amigalife.org" in the link with "ae.arosworld.org".

@AMIGASYSTEM

I'm starting work on this months but. I reviewed the old post and it looks like the problem is visible with TKUnpaker tool. Please provided me an archive with this tool and all needed supporting files in correct directory structure, so that I just extract that archive on top of clean AROS build and can reproduce the problem.

Also, have you tried if Scalos and/or Magellan under AROS x86 behave the way you describe Workbench on OS3 behaves?

TKUnpaker can be found in the attached link (the site no longer exists but you can reach it from archive.org), I haven't used this tool for years on OS3, if you have trouble setting it up, I can try to install it from scratch on a clean OS3.

http://web.archiv...tributions


I have never tried to use it on these systems, I will install a system this evening and let you know.