Installer picking wrong @default-dest

[chris]

Installer often picks up TextClip: as the default location to put installations. It is supposed to pick Work: or the drive with the most space (it should never, ever, pick TextClip: owing to it not being a real drive)

This script shows the problem (at least here; YMMV):

Code: Select all

(message @default-dest (all))

(exit (quiet))
(welcome)

I reported this ages ago and ISTR being told that it was fixed. I don't think a newer version of Installer has been included with any updates since. Can we get this in Update 4 please?

[Slayer]

Can't say I've ever noticed that but perhaps its because I select Expert? Another thing I'm curious about today... hmmm

But you're right, this isn't a great location for a newbie to install anything in...

I wonder if you went ahead would it come back with error unknown disk size...

[chris]

Can't say I've ever noticed that but perhaps its because I select Expert?

Even in Expert mode it should still be picking that initially, or showing it after an install which doesn't manually set @default-dest to the actual install location.

I wonder if you went ahead would it come back with error unknown disk size...

The Info command shows a size for TextClip:, I guess it would fail when trying to write to it though. Actually I have no idea what TextClip: is, what it does or how it works.

[xenic]

@chris
I did some testing with this and it appears to me that the problem might be with TEXTCLIP: and not Installer. If you enter the "Info" command in a shell you will see that TEXTCLIP: is listed like a storage device. It even has a volume name (TextClip) and shows available storage space. Maybe OS4 has a new method to distinguish storage devices from i/o devices but it appears that previous methods are fooled by TEXTCLIP: although some newer system functions like ASL are able to tell the difference (ASL requesters don't show TEXTCLIP: as an available storage device). Either TEXTCLIP: needs to be fixed or other system commands & programs need to be fixed.

[chris]

@chris
I did some testing with this and it appears to me that the problem might be with TEXTCLIP: and not Installer. If you enter the "Info" command in a shell you will see that TEXTCLIP: is listed like a storage device. It even has a volume name (TextClip) and shows available storage space.

It does, but here the available space is not the highest available - I have other volumes with more space which Installer should be picking first.

[xenic]

@chris
Check the Info command output (default). The free size for disks is listed in blocks but the size for TEXTCLIP: is actually the same as the bytesize of free memory available. It looks to me like Info is getting free byte size from TEXTCLIP: when it is expecting block size. If the same thing is happening to Installer then the problem is in TEXTCLIP: and not necessarily Installer. If Installer is getting the wrong data from TEXTCLIP: then it will act on that erronious data.

[chris]

@chris
Check the Info command output (default). The free size for disks is listed in blocks but the size for TEXTCLIP: is actually the same as the bytesize of free memory available. It looks to me like Info is getting free byte size from TEXTCLIP: when it is expecting block size. If the same thing is happening to Installer then the problem is in TEXTCLIP: and not necessarily Installer. If Installer is getting the wrong data from TEXTCLIP: then it will act on that erronious data.

...or maybe the blocksize of TEXTCLIP is 1 byte/block, as the Size column is correct. Installer might be requesting the number of free blocks, rather than the number of free bytes. In which case it is Installer at fault.

[xenic]

@chris

...or maybe the blocksize of TEXTCLIP is 1 byte/block, as the Size column is correct. Installer might be requesting the number of free blocks, rather than the number of free bytes. In which case it is Installer at fault

As much as I hate to be wrong I think I have proven your theory. I have an alternate boot partition that is almost the same size as my main boot partition. I disabled mounting of all other partitions and removed the TEXTCLIP device from DEVS:DosDrivers. My DH0: is SFS with a block size of 512 and my DH5: is FFS with a block size of 1024. Because of the difference in block size, DH0: has more blocks free but DH1: has more bytes free. Installer picks DH0: as the default installation location because of the greater number of blocks available when in fact DH1: has more space available in bytes.

However, TEXTCLIP should not be showing up as a storage device to some programs. TEXTCLIP is basically a pipe-like extension of the Clipboard device and should be mounted like the PIPE device. PIPE doesn't show up as a storage device and neither should TEXTCLIP. My conclusion is that Installer needs to be fixed to evaluate free space in bytes instead of blocks and TEXTCLIP needs to be changed not to appear as a storage device (it should act like PIPE).

[chris]

@chris

...or maybe the blocksize of TEXTCLIP is 1 byte/block, as the Size column is correct. Installer might be requesting the number of free blocks, rather than the number of free bytes. In which case it is Installer at fault

As much as I hate to be wrong I think I have proven your theory. I have an alternate boot partition that is almost the same size as my main boot partition. I disabled mounting of all other partitions and removed the TEXTCLIP device from DEVS:DosDrivers. My DH0: is SFS with a block size of 512 and my DH5: is FFS with a block size of 1024. Because of the difference in block size, DH0: has more blocks free but DH1: has more bytes free. Installer picks DH0: as the default installation location because of the greater number of blocks available when in fact DH1: has more space available in bytes.

However, TEXTCLIP should not be showing up as a storage device to some programs. TEXTCLIP is basically a pipe-like extension of the Clipboard device and should be mounted like the PIPE device. PIPE doesn't show up as a storage device and neither should TEXTCLIP. My conclusion is that Installer needs to be fixed to evaluate free space in bytes instead of blocks and TEXTCLIP needs to be changed not to appear as a storage device (it should act like PIPE).

Good investigation. Now all we need is somebody in this thread who can officially report bugs

[xenic]

@chris
Since these forums are the official place to report bugs there's really no excuse for any confirmed problem not to be fixed. The excuse that the devs & beta testers can't read all the posts on all the Amiga forums isn't going to work anymore. It's all right here on the Hyperion forums