Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Alten Algorithmus für DeflateStream nutzen
T-Man
myCSharp.de - Member



Dabei seit:
Beiträge: 210
Herkunft: Bremen

Themenstarter:

Alten Algorithmus für DeflateStream nutzen

beantworten | zitieren | melden

Der Algorithmus, den der DeflateStream verwendet hat sich geändert. Vermutlich mit Framework 4.7.2, genau weiß ich es nicht. Meine Anwendung ist für 4.6.1 gebaut, trotzdem hat sich das Verhalten geändert.
Mein Problem: Ich speichere Daten komprimiert und nicht doppelt. Die Id für einen Stream habe ich aus dem Hash des komprimierten Streams gebildet. Damit kann ich nach Duplikaten suchen. Solange der Algorithmus sich nicht geändert hat, hat das funktioniert.
Jetzt nicht mehr. Wird jetzt ein Dokument komprimiert, dass ich früher schonmal hatte, sieht der komprimierte Stream anders aus und hat einen anderen hash. Ich finde also das Duplikat nicht mehr.

Die saubere Lösung für mich wäre, den Hash des Originals zu verwenden. Nun habe ich aber schon Millionen alte Datensätze, für die ein Update nicht mal eben schnell gemacht ist.

Daher würde ich gerne als Zwischenlösung auf den alten Algorithmus zurückgreifen.

Weiß jemand, ob und wie das geht?

Ich habe folgenden Schalter gefunden, der leider nicht hilft:
<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

DoNotUseNativeZipLibraryForCompression gibt's leider nicht.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.852

beantworten | zitieren | melden

Siehe Decompression changes in DeflateStream
Zitat
Support for decompression by using Windows APIs is enabled by default for applications that target .NET Framework 4.7.2. Applications that target earlier versions of .NET Framework but are running under .NET Framework 4.7.2 can opt into this behavior by adding the following AppContext switch to the application configuration file:
<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

Würde mich wundern, wenn es das wirklich nicht geben würde. Wäre ein Bug, der sicherlich jemanden vorher aufgefallen wäre.
Sicher, dass das Setting zieht?
private Nachricht | Beiträge des Benutzers
T-Man
myCSharp.de - Member



Dabei seit:
Beiträge: 210
Herkunft: Bremen

Themenstarter:

beantworten | zitieren | melden

Wie schon gesagt, hilft das nicht.
Der Schalter ist scheinbar für's dekomprimieren, nicht für's komprimieren.
private Nachricht | Beiträge des Benutzers
T-Man
myCSharp.de - Member



Dabei seit:
Beiträge: 210
Herkunft: Bremen

Themenstarter:

beantworten | zitieren | melden

Sowohl true als auch false liefern das selbe Ergebnis und das ist ein anderes, als vor einiger Zeit.
Kann leider nicht genau sagen, seit wann.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.852

beantworten | zitieren | melden

Ah; sorum geht der Hase.
Wenn Du auf den alten Kompressionsalgorithmus keinen Zugriff mehr hast / haben kannst; dann musst im Zweifel Deinen Datenbestand migrieren.

Da .NET Framework 4.7.2 allgemein große Breaking Changes beim Thema Crypo hat, wirst Du da evtl. langfristig nicht drum herum kommen.
Wir speichern bei solchen Hashes auch immer den Identifier des Algorithmus ab; so kann man das bei den meisten Anwendungen zur Laufzeit migrieren (zB. User Passwords stehts mit dem neuesten, sichersten Algorithmus speichern).
private Nachricht | Beiträge des Benutzers
T-Man
myCSharp.de - Member



Dabei seit:
Beiträge: 210
Herkunft: Bremen

Themenstarter:

beantworten | zitieren | melden

Das ich migrieren muss ist mir klar.
Werde ich tun.
Ich hatte nur gehofft, einen sehr schnelle fix zu finden, denn die Migration wird ein wenig dauern und bis dahin funktioniert die Duplikatserkennung nicht mehr richtig. Das Produkt ist komplex und wir releasen nicht alle paar Tage. Einen Hotfix könnte ich schnell nachschieben, die Migration nicht.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.852

beantworten | zitieren | melden

Bist Du gezwungen, auf .NET Framework 4.7.2 zu gehen?
Wenn nicht kannst Du ja problemlos eine Soft Migration durchführen:
- Weiterhin auf die alten Hashes gehen
- Neue Hashes generieren
- Wenn alle Hashes durch sind, dann auf 4.7.2 gehen
private Nachricht | Beiträge des Benutzers
T-Man
myCSharp.de - Member



Dabei seit:
Beiträge: 210
Herkunft: Bremen

Themenstarter:

beantworten | zitieren | melden

Das Produkt haben viele Kunden auf eigenen Servern. Das Kind ist schon in den Brunnen gefallen. :-(
Kann denen nicht sagen, sie sollen Windows- oder Frameworkupdates zurücknehmen. Das Problem ist gestern aufgefallen. Wie lange es schon da ist, also was genau der Auslöser ist, kann ich nicht nachvollziehen. Ich vermute, dass es Framework 4.7.2 ist, muss aber nicht sein. Ich weiß nur, dass jetzt das compress andere Ergebnisse liefert, als vor einiger Zeit. Könnte den Zeitpunkt zwar theoretisch eingrenzen, aber das ist leider auch nicht trivial. Da arbeite ich lieber weiter an der richtigen Lösung.

Hatte halt die Hoffnung, dass es da einen einfachen Schalter gibt.
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.852

beantworten | zitieren | melden

In den Changelogs von 4.7.2 wird ja auf die Breaking Changes der Compression hingewiesen.
Wird also schon die Ursache sein.
private Nachricht | Beiträge des Benutzers