"
Ja, Ihre Kritik ist formal korrekt. Sie zielen auf den Unterschied zwischen
Speicherintegrität und
Ausgabeintegrität.
Hier die präzise IT-Definition:
---
### 1. Datenintegrität ist betroffen – aber nicht die Persistenz
- Storage-Integrität (ESE-DB): Gegeben.
Windows.db enthält den korrekten Pfad.
- Query-Integrität (Retrieval): Verletzt. Die Abfrage liefert kein sound (vollständiges) Ergebnis.
In der Datenbanktheorie:
SQL:
SELECT * FROM Apps WHERE Name LIKE '%<input>%' ORDER BY Relevance;
Wenn der
Relevance-Score für Web-Ergebnisse höher gewichtet ist als für lokale Apps, ist der Resultset
nicht mehr vollständig bezüglich des zugrunde liegenden Datensatzes. Es ist eine
funktionale Verfälschung der Ausgabe.
### 2. Formale Klassifikation
Es handelt sich nicht um eine
Korruption (bit-level error), sondern um einen
logischen Fehler in der Query-Evaluation:
- Constraint-Verletzung: Die funktionale Spezifikation "Eingabe = App-Name → Ausgabe = App-Pfad" wird nicht erfüllt.
- Selektiver Filter: Die Aggregationsebene (
SearchHost.exe) unterdrückt den korrekten Datensatz aktiv durch eine fehlerhafte Priorisierungslogik.
### 3. Fazit für die Fehlerdiagnose
| Ebene | Status | Defekt? |
|-------|--------|---------|
| Storage (Windows.db) | Konsistent | Nein |
| Indizierungsdienst (SearchIndexer) | Läuft | Nein |
| Abfragelogik (Ranking) | Verfälscht |
Ja |
| UI-Rendering | Inkonsistent |
Ja |
Ihre Aussage ist korrekt: Auch wenn die Datenbank heil ist, ist die
informatorische Integrität der Suchfunktion gebrochen. Das System verhält sich deterministisch falsch – eine "functional data integrity violation" auf der Ausgabeebene."
Da warte ich noch ein Jahr und Win11 lässt sich komplett abschalten.
