OS4.1 bugs

@Cyborg

I think I've just found another (small) one in the WB text mode.
Look at the following picture :

the first line without any file is of the same color of the previous one, defeating the alterning effect.
The problem raises when enabling vertical stripes, I guess this is because in normal mode (no vertical stripes) there is two colors, a dark and a light one. With vertical stripes on there are three colors a lighter one, the same light one and the same dark one where in fact there should be four colors a lighter, the same ligth one, a new dark one (less dark than previous dark), the same dark one.

@Raziel

A little update to my "copy to USB" problem.

It was NOT the file comments, rather some "forbidden" chars in the file names which causes the copy procedure to go bork.

I found at least some question marks "?" in the filenames. Those exactly weren't breaking the copy process, but some files after them made the whole procedure go boom.

Dunno if it's because of the FAT fs used on the USB stick or "copy" (ASyncWB copy) to choke ... anyway, problem solved here by erasing all the baddies

So far it looks like I got rid of random lock ups completely. I've been trying to think what has changed since I had them last time. Two things have changed: the ADSL modem and the DVD drive. I don't remember changing any software lately. (I got those lock ups still after installing those two OS QuickFixes.) So in the end it was a hardware issue, it seems. I'm very happy now. But I can't understand how a modem or a DVD drive could cause those lock ups. I'm using the DVD drive quite rarely and the old modem is (like the new one) 5 port switch/router. So I can't understand how it could cause any trouble. (I guess it has usually something to do with buggy firmwares in devices.)

If anybody's interested: the old modem is TeleWell TW-EA500, the new one is A-Link RR24AP, the old DVD is Lite-On (I don't remember the model) and the new one is LG GSA-H54N.

PS. I think it's a good idea to use the latest stuff from well known manufacturers instead of buying some cheap stuff or recycling components from old computers to stay out of any troubles.

EDIT: Now I remembered what else I've changed lately. I removed HTTP handler. Maybe that was the problem. I'll put it back someday to find out but not yet.

@Raziel

finally my USB 16GO FAT32 copy problem here:

http://www.amigans.net/modules/newbb/ ... hp?topic_id=2607&forum=22

look like the one raziel have seen also.

See the link to konw what happened exactly but in short.

1. copy the DH0: to 16go USB2 FAT32 give a crash first time with big files and 8+3 files. crash when copying amicygnix drawer.

format to FAT32 the USB key again with a XP PC.

2. copy the DH0: again and OK this time but 11 .dummy files
(1 bytes each) can't be copied (source is share/icons/... from amicygnix). the copy failed with opus4 and dirmaster2 AOS4.1.

strange because all the others .dummy files copied without problems. maybe too much .dumy files or too long path ???

symptoms:

copy failed make a getsize with dopus4 show zero bytes on the drwaer who must have the .dummy files but when try to copy again, filemanagers said that the file allready exist.

this problem with the 11 .dummy files.

also the ROX main exe (from rox-filer drawer) give an error rom dopus4 but the copy is OK finally.


Please try to copy: -amicygnix/cygnixPPC/share/icons to an USB empty key formated with FAT32 with aos4.1/SAM.

I was chasing a bug in my FLIC datatype, and it turns out that it doesn't work for files on the JXFS filesystem.

I've tracked it down to ChangeFilePosition() - at least OFFSET_CURRENT - not seeking through the file by the correct number of bytes.

Start at offset 128
Skip forward 23300 bytes
GetFilePosition() reports us as being at offset 144
Skip forward 778 bytes
GetFilePosition reports 160

Probably needs a little bit more investigation but there certainly appears to be a problem there.

edit is it skipping forward a maximum of 16 bytes??

ChangeFilePosition OFFSET_CURRENT is definitely broken when using JXFS. With my test code (below) OFFSET_CURRENT isn't changing the file position at all when run on a JXFS partition, however it works on RAM: and SFS (don't have a FFS or SFS2 partition to test those).

Moreover OFFSET_END is completely broken and not working on any FS.

@Chris

Quote:
You should use IDOS->ChangeFilePosition(fh,-100,OFFSET_END); +100 will move you outside of the file ! It looks like OFFSET_CURRENT is the only one that doesn't work.

@TSK

Oops, good point

@Chris

Besides the fact that every one of those functions actually has a return code, there is no checking being done.
Also, the 'posn' variable is supposed to be signed.

However, semantics aside, you did actually find an issue with OFFSET_CURRENT with JXFS filesystem, the fix will be in the update due out shortly.

Thanks for finding that.

@colinw

IDOS->ChangeFilePosition() returns -1 in all those cases.

I have another one related to JXFS

Creating hard links actually creates a copy of the file.

eg, create a file "test1" on a JXFS partition
CD to that partition
type "makelink test2 test1"
edit test1
- note that test2 still shows the old contents (and that the files aren't underlined in WB)

@ all

I have just installed OS4.1 on my XE-G4. When I try to move
an icon of any type to a new position, I can move them in
any direction for a few pixels and then they go back to the
original position as soon as I let go of the mouse button.
I can move a window about without any problems.
I installed OS4.1 on a freshly formated partion with that
partiton with a DOS7 Standard File System, Fast File System,
Long file names, Block Size 2048, Buffers 500, Max Transfer
7FFFFFFF, Mask FFFFFFFE as previously done with OS4.0 as
there is nothing in the 4.1 instructions to say anything
different.

I have my SWAP partion set as per the manual.

As recommended I have a Radeon 9250 AGP with 256DDR Memory.
Tower internal is a single 512MB memory module that came with
the system from new.

I cannot see anything previously posted about this, so is
this a know bug that has been solved?

regards
clint

@clint

Hi Clint,

On my ?A1c/OS4.1 setup I also came across this bug.
It took me quite a while to find out what the reason was.

Just go into GUI preferences > Options and disable the
Compositing Mode for Layers. Then Drag n' Drop of icons
will work again.

I hope the OS 4.1 developers will fix this bug.

Regards,
KoTLER

@Kotler

Thanks for that. Thats the answer, works for me to.

Best regards
clint

@TSK

Not a bug, but referring to your message #90. Yes, it is possible to add datatype objects to reaction windows. There's a simple way to LAYOUT_AddChild,...,CHILD_DataType,TRUE,... way. Another way: with my BibVision program I use embedded text datatype object and the object is added dynamically, something like:

if (bibobj = NewDTObject(name,DTA_GroupID,GID_TEXT,ICA_TARGET,ICTARGET_IDCMP,GA_ID,GADM_TEXT,TAG_DONE))
{
bibwin->IsDataType = success = TRUE;
SetGadgetAttrs(bibwin->Gads[GADM_AREA],bibwin->Win,NULL,
LAYOUT_ModifyChild,bibwin->Gads[GADM_TEXT],
CHILD_ReplaceObject,bibobj,
TAG_DONE);
bibwin->Gads[GADM_TEXT] = (struct Gadget *)bibobj;
SetGadgetAttrs(bibwin->Gads[GADM_SCROLLY],bibwin->Win,NULL,
ICA_TARGET,bibwin->Gads[GADM_TEXT],
TAG_DONE);
SetGadgetAttrs(bibwin->Gads[GADM_SCROLLX],bibwin->Win,NULL,
ICA_TARGET,bibwin->Gads[GADM_TEXT],
TAG_DONE);
RethinkLayout(bibwin->Gads[GADM_AREA],bibwin->Win,NULL,FALSE);

and the IDCMP hook:

switch (imsg->Class) {

case IDCMP_IDCMPUPDATE:
while (tag = NextTagItem(&tstate))
{
tidata = tag->ti_Data;
switch (tag->ti_Tag)
{
/* Time to refresh */
case DTA_Sync:
{
struct BibleWindow *bibwin;
LONG gaid;

GetAttr(WINDOW_UserData,winobj,(ULONG *)&bibwin);
GetDTAttrs((Object *)bibwin->Gads[GADM_TEXT],DTA_TotalVert,&total,DTA_VisibleVert,&visible,GA_ID,&gaid,TAG_DONE);
value = bibwin->CurrentLine;
if (value > total-visible)
value = total-visible;
SetDTAttrs((Object *)bibwin->Gads[GADM_TEXT],win,NULL,DTA_TopVert,value,TAG_DONE);
SetGadgetAttrs(bibwin->Gads[GADM_SCROLLY],win,NULL,SCROLLER_Top,value,SCROLLER_Total,total,SCROLLER_Visible,visible,TAG_DONE);
GetDTAttrs((Object *)bibwin->Gads[GADM_TEXT],DTA_TopHoriz,&top,DTA_TotalHoriz,&total,DTA_VisibleHoriz,&visible,TAG_DONE);
SetGadgetAttrs(bibwin->Gads[GADM_SCROLLX],win,NULL,SCROLLER_Top,top,SCROLLER_Total,total,SCROLLER_Visible,visible,TAG_DONE);
RefreshGList(bibwin->Gads[GADM_AREA],win,NULL,1);
}
break;
}
}

Sorry if a bit off-topic.

Marko

@blmara

Thanks !

There seems to be a problem with Notepad and Workbench and Locale's preferred languages list.

If I specify:
English ISO-8859-1
German

Then both Notepad, Ed, UnArc and the Grim Reaper start shouting at me in German.

If I specify:
English-British ISO-8859-15
English
German

Then not only Notepad, Ed, UnArc and Grim Reaper are in German, but Workbench and the Shell are too!

I suspect they are manually parsing the preferred languages list, and not stopping at the first supported language as they are supposed to.

This makes the preferred languages list not very useful, as people would tend to put their first language at the top, and other languages they might not be so comfortable with underneath.

I always used to have my list as English, German under OS3.x and don't recall seeing this problem. I'm not quite sure why I didn't already have it set like that under OS4.1 (maybe this bug has been there since the early days of 4.0?)

Edit I keep adding system programs to the list - appears to be more widespread than I first thought, so I'm strongly suspecting a bug in locale.library OpenCatalog() now.

@all

see this thread post #11:

http://www.amigans.net/modules/newbb/ ... t_id=34479#forumpost34479

sorry for doubleposting but like that my USB AOS4.1 bugs problem is reported on this thread.

Another bug that I have and this is for the peg2 version is that if I try to boot Os41 after I power on peg2 I just get a screen full of garbage gfx.... Now, if I boot MOS then reset (even from the reset button of the case) I can boot ok in Os41. This happens for the install cd as well for my installed system. Tried with 2 different Radeon 9200s. That's quite annoying as there are times when I want to go straight into Os41 and I have to boot MOS first then reset and enter Os41. Anyone else had this bug occuring?

I found out hard way one problem is still there in workbench.library 53.4. If I use OpenWorkbenchObject() function to start a program which contains AmiUpdate support code (or any code using SetVar(), I guess) it overwrites the executable itself instead of saving variable content into ENV:AppPaths where it should go. If I'll use SystemTags("WBrun blaablaa",blaablaa...) then it works like it should without problems.