Installer could/should create all indexes present on source disk

[umccullough]

Perhaps it makes sense to have the Installer create, on the target disk, all indexes present on the source disk. It should do this *before* copying files so that those indexes get updated during installation (either that, or do a full reindex after creating the indexes).

This would possibly alleviate the problem I mentioned in ticket #6085 for example.

I'm filing this as an enhancement request as I'm not sure it can be called a bug.

[diver]

I wonder, how this would work if one wants to use Tracker to copy OS from source disk? This was one of a beauty of BeOS I wouldn't want to lose in Haiku.

[umccullough]

Replying to diver:

I wonder, how this would work if one wants to use Tracker to copy OS from source disk? This was one of a beauty of BeOS I wouldn't want to lose in Haiku.

It's my understanding that BeOS also did nothing to re-create indexes on the target disk. But perhaps BeOS' partitioning tool automatically added a few default critical indexes.

In any case, at the moment, using Tracker to install Haiku rather than Installer would likely suffer the same consequence I susepct.

[stippi]

Could you please check with hrev40816? I have not tested these changes at all, but the source volume indices should be mirrored. It should work when installing from a live-booted USB stick, when booted from a live-CD I don't know who "simulates" these indices and if trying to query them will work as well.

[mmlr]

Replying to stippi:

... when booted from a live-CD I don't know who "simulates" these indices and if trying to query them will work as well.

It won't work. While the attribute_overlay adds attribute support, there is neither query nor index support. It will work for the anyboot images as they are BFS.

Personally I think this should be handled as a pre-install script, triggered by the installer, or manually if someone wanted to go that route. Having it built into the installer makes one really dependent on it.

[stippi]

In hrev40820, I've fixed the bugs in the implementation. My tests were with QEMU and two BFS hard disk images. So I haven't yet tested how the code behaves when Installer runs from an ISO. It depends a bit on what fs_open_index_dir() returns when there is no index dir. If it returns B_ENTRY_NOT_FOUND, then Installer will behave as before. Apparently it worked fine when booting from CD directly into Installer. It should work now according to my testing when booting from a BFS volume in Live mode. Don't know what happens when booting into the ISO Live-CD and invoking the Installer manually. If I understand thinks correctly it would probably trigger the problem as reported in this ticket.

[stippi]

BTW, it would indeed work to put stuff into the InstallerInitScript. First it could try to invoke mkindex --copy-whatever. Then it could try to create the known to be required indices (ignoring if they already exists). I would not remove the code from Installer, which is pretty generic and does not hurt if it tries to create indices already there.

[umccullough]

First I tested using the anyboot USB stick to install with hrev40815 and confirmed the behavior mentioned in #6085 was still present, then I tested the same scenario with hrev40822 and verified that the behavior in #6085 was resolved.

Looks like it worked for that particular test case.

Thanks for tackling that one stippi!

[umccullough]

Tested with ISO Live CD.

Launched Installer from Terminal to see output.

It fails on fs_open_index_dir() with "Operation not supported"

[stippi]

Since hrev40836, Installer will now always create all needed indices. Thanks for the testing!

[diver]

How about moving creation of indexes to InstallerInitScript?