dos.library/Info() problem

[JosDuchIt]

am using SAM440ep OS4.1 update 4

I am using a directory manager written in Gui4Cl. The described problem started with i think OS4.1 update 3 and got worse with update 4


The first lines in the Directory listview, when no directory has been selected, look now (update 4) as
CD0: 1515947440:1515947440 ADCD_2.1:
DU0: 017G:020G Amiga OS 4:
DU1: 044G:060G Datas:
DU2: 030G:046G BackUp:
ENV: No:Disk
ICD0: No:Disk
IDF0: No:Disk
RAM: 1515947440:1515947440 RAM Disk:
RANDOM: No:Disk
TEXTCLIP: No:Disk
URL: No:Disk
USB0: 1515947440:1.8G BUpOS4:

CD0 contains a CDROM and USB0: an USBstick
The long numbers that now take the place of free memory for CD0: RAM: and USB0: and for total memory for CD0: and RAM may vary with the session.
Before, i think, update 3 all figures of free and total memory looked OK
With update 3 i did not see the long numbers shown, but a small character looking like a non ASCII character in some editors.

To get those sizes Gui4Cli uses the dos.library/Info() function.

As nothing changed here in the source, and since for other diskunits free and total memory are represented correctly i can only suspect the updates.

I know there is a newwer GetDosInfo function that may not have the problem

Code: Select all

// ************************ GET DEVICE INFO ***********************
// - get size etc, store it in the comment field..
// ================================================================

void getdevinfo() //OS4E was int void
{
	ALIGNED struct InfoData inf; //OS4E was __aligned
	ALIGNED BPTR lk; //OS4E was __aligned
	BOOL flag;
	struct filelist *fl, *f;
	DOUBLE size, free;
	char buff[15], devname[80];

	for (fl = TOPlist; fl; fl = fl->next)
	{	if (fl->type == FL_DEV)
		{ 
			devname[0] = 0;
			for (f=TOPlist, flag=0; f && (!flag); f = f->next) /* get volume name */
			{	if ((f->type == FL_VOL) && (f->task == fl->task))
				{	strcpy (devname, f->name); ++flag;
			}	}

			if (devname[0])
			{ 
				if (lk = Lock (fl->name, ACCESS_READ))
				{	Info (lk, &inf);
					UnLock (lk);
					size = (DOUBLE)inf.id_NumBlocks * (DOUBLE)inf.id_BytesPerBlock;
					free = ((DOUBLE)inf.id_NumBlocks - (DOUBLE)inf.id_NumBlocksUsed) * (DOUBLE)inf.id_BytesPerBlock;
					formatsize (free, fl->comment);
					strcat (fl->comment, ":");
					formatsize (size, &fl->comment[strlen(fl->comment)]);
					strcat (fl->comment, " ");
					if (inf.id_NumSoftErrors > 0)
					{	stcl_d (buff, inf.id_NumSoftErrors);
						strcat (fl->comment, buff);
						strcat (fl->comment, " Error(s)");
					}
					else if (inf.id_DiskState == 81)
						strcat (fl->comment, "Validating..");
					else
						strcat (fl->comment, devname);
				}
			}
			else
				strcpy (fl->comment, "  No:Disk");
		}
	}
}

/******************** FORMAT SIZE *********************/

void formatsize(DOUBLE size, char *buff)
{
	char type = 'B', bf[20];
	LONG gb, len;

	if (size >= 1024)
	{	type = 'K'; size /= 1024;
		if (size >= 1024)
		{	type = 'M'; size /= 1024;
			if (size >= 1000) // 1000 for alignment
			{	type = 'G';
	}	}	}

	len = (LONG)size;
	if (type != 'G')	// up to MB
	{	sprint (buff, "%03ld%lc", len, type);
		return;
	}
	if (size < 1024)	// mid 1000-1024..
	{	sprint (buff, " <1G", NULL);
		return;
	}

	// handle gigabytes differently..
	gb  = (LONG)(size / 1024);
	len = stcl_d (bf, gb);
	if (len > 1)
		sprint (buff, "%03ldG", gb);
	else
	{	buff[0] = *bf;
		buff[1] = '.';
		gb   = size / 1024;
		len  = size - (gb * 1024);
		len  /= 100;
// printf ("dub=%f, size=%f, len=%ld\n", dub, size, len);
		stcl_d (&buff[2], len);
		buff[3] = 'G';
		buff[4] = '\0';
	}
}

[xenic]

@JosDuchIt
I can't really compile your code out of context from the rest of your code for testing but I do wonder about alignment issues that are known to exist on SAM. I sure wish we had access to the UtilityBase forums because I can't remember exactly what was stated about SAM alignment. I seem to remember that you must use a compile option to enforce proper alignment when using -lm (math lib) on a SAM. I also wonder if a DOUBLE remains aligned if it is passed to another function on the stack. Alignment may not be the issue but I thought I'd mention it since nobody else has any suggestions to solve your problem.