TStringList.SaveToFile ERROR_NOT_SUPPORTED

[ralfschwalbe]

Hallo,

ich habe auf manchen Windows 10 Rechnern seit ca. 14 Tagen das Problem, dass ich beim Speichern von Stringlisten vom Client auf dem Server (über UNC-Pfad) einen ERROR_NOT_SUPPORTED bekomme...

Bsp.: "Datei "\\server\verzeichnis\Formular.txt" kann nicht erstellt werden. Die Anforderung wird nicht unterstützt."

Alle Rechte sind vorhanden. Die Methode SaveToFile macht ja intern nur:

Delphi-Quellcode:

  Stream := TFileStream.Create(FileName, fmCreate);
  try
    SaveToStream(Stream, Encoding);
  finally
    Stream.Free;
  end;

Gibt es Ideen dazu? Vielen Dank.

[BerndS]

Ist das eine SMB1 Freigabe?

[ralfschwalbe]

Vielen Dank. Ich denke nein. Alles Server 2016 und 2019 mit aktuellen Updates oder (als Ausnahme... ein Windows 10 prof. als "Server"). Da gibt es standardmäßig meines Wissens kein aktiviertes SMB1 mehr... Oder?

Aber... Was hätte das damit zu tun?

[BerndS]

War nur eine Vermutung da es dem hier ähnelt. Das Deaktivieren auf den Clients sollte dann helfen.

[ralfschwalbe]

Ok. Danke. Werde ich trotzdem prüfen...

[ralfschwalbe]

So... geprüft... SMB1 ist deaktiviert. Das war es also nicht... Gibt es noch andere Ideen?

Müsste man beim Erstellen des Filestreams über das Netzwerk nicht noch einen ShareMode angeben? Hätte man dazu (wir machen ja

Delphi-Quellcode:

TStringlist.SaveToFile

) überhaupt eine Chance?

[ralfschwalbe]

Aus System.Classes:

Delphi-Quellcode:

procedure TStrings.SaveToFile(const FileName: string; Encoding: TEncoding);
var
  Stream: TStream;
begin
  Stream := TFileStream.Create(FileName, fmCreate);
  try
    SaveToStream(Stream, Encoding);
  finally
    Stream.Free;
  end;
end;

Encoding setze ich nicht explizit.

[Uwe Raabe]

Zitat:

Zitat von ralfschwalbe (Beitrag 1454352)

Müsste man beim Erstellen des Filestreams über das Netzwerk nicht noch einen ShareMode angeben?

So wie ich das sehe, ist die Datei bei fmCreate für die Dauer des Zugriffs für andere gesperrt. Kann es sein, daß eine unter diesem Namen vorhandene Datei im Netz noch von anderer Stelle geöffnet ist oder einen Schreibschutz bzw. ein Löschverbot hat?

[ralfschwalbe]

Danke für die Antwort. Wir hatten das auch schon vermutet. Ich halte das aber eher für unwahrscheinlich, da nur ein Client am Server ist. Möglicherweise wird die Ini aber am Server durch einen Antivirus (oder Windows selbst?) oder ähnliches "festgehalten"...

Allerdings... Sollte ich dann nicht eine andere Fehlermeldung bekommen? Und warum tritt das Problem erst ab Mitte Dezember 2019 (mittlerweile bei fast 20 Kunden) nach fast 10 Jahren ohne Sorgen auf?

Fragen über Fragen...

[hoika]

Hallo,

Zitat:

Und warum tritt das Problem erst ab Mitte Dezember 2019

neues Windows-Update?

[ralfschwalbe]

Ja, meine Vermutung. Aber welches... Und warum ERROR_NOT_SUPPORTED und nicht einfach ERROR_ACCESS_DENIED?

[Luckie]

Hat das Windows Update eventuell einen benötigten Dienst deaktiviert? Vielleicht mal in diese Richtung forschen?

[Rolf Frei]

Versuch doch auch mal diese Datei mit dem selben Namen via Notepad zu speichern. Bekommst du da auch einen Fehler?

[Luckie]

Oder mit dem Explorer dort eine Datei zu erstellen. Funktioniert das auch nicht, dürfte es sich um ein generelles Problem handeln.

[rwalper]

Ich hatte vor 2 Jahren das gleiche Problem bei nur einem einzigen Kunden. Da hat wirklich die Angabe des Sharemodes geholfen,
beim Lesen

Delphi-Quellcode:

TStream.Create(FileName, fmOpenRead or fmShareDenyWrite)

und beim Schreiben

Delphi-Quellcode:

TStream.Create(FileName, fmCreate or fmShareExclusive)

bzw.

Delphi-Quellcode:

TStream.Create(FileName, fmOpenWrite or fmShareExclusive)

[squetk]

Wir haben hier mit dem gleichen Problem zu kämpfen: Schreibende Zugriffe auf ein Netzwerklaufwerk bringen den Fehler ERROR_NOT_SUPPORTED, wenn sie eine bestehende Datei erweitern wollen.
Und das erst seit Dezember 2019.
Tragisch für unsere Kunden ist dass es auch Software betrifft, die nicht von uns erstellt wurde.

[luka]

Ich werfe einmal den Begriff Manipulationsschutz ein.
Versuche mal diesen abzuschalten, funktioniert danach der Zugriff wieder.

Neue Dateien können erstellt werden, aber diese können dann nicht mehr verändert werden.
Mit dem Editor kann die Datei verändert werden.

[himitsu]

Wir haben auch grade den ersten Kunden.

Nur bei einem von mehreren Rechnern taucht dieser Fehler auf.
Ist bei euch auch Windows 7 der zugreifende Client?

Ja, ich weiß dass Win7 seit Januar offiziell tot ist, aber dann wäre die Lösung ein Upgrade. :stupid:

[squetk]

Nein, es betrifft auch PC's mit Windows 10.

[ralfschwalbe]

Zitat:

Zitat von rwalper (Beitrag 1454522)

Ich hatte vor 2 Jahren das gleiche Problem bei nur einem einzigen Kunden. Da hat wirklich die Angabe des Sharemodes geholfen,
beim Lesen

Delphi-Quellcode:

TStream.Create(FileName, fmOpenRead or fmShareDenyWrite)

und beim Schreiben

Delphi-Quellcode:

TStream.Create(FileName, fmCreate or fmShareExclusive)

bzw.

Delphi-Quellcode:

TStream.Create(FileName, fmOpenWrite or fmShareExclusive)

Funktioniert tatsächlich! Allerdings ist das Problem, dass Delphi in

Delphi-Quellcode:

TStrings.SaveToFile

auch nur

Delphi-Quellcode:

Stream := TFileStream.Create(FileName, fmCreate);
  try
    SaveToStream(Stream, Encoding);
  finally
    Stream.Free;
  end;

macht... Also was tun? Alle Stringlisten "SaveToFile" mit eigener Speicherroutine versehen? Is blöd...

[sabba]

Hallo,

wir haben das Problem jetzt auch schon mehrfach bei unseren Kunden gehabt. Allerdings können wir nicht nachvollziehen unter welchen Konstellationen das Problem auftritt.
Unsere Erfahrung ist, dass es meistens nach einem PC-Neustart des Clients einfach wieder geht.

Könnt ihr das immer nachvollziehen bzw. reproduzieren?

Dennis

[Klaus01]

.. es wäre etwas Mehraufwand
die StringList einem FileStream (mit den entsprechenden Parameter erstellt) übergeben und diesen abspeichern.

Grüße
Klaus

[ralfschwalbe]

Hat denn jemand herausgefunden welches Windowsupdate schuld war und vielleicht auch warum? Wir nämlich nicht... :oops: Wir haben die Speicherroutinen umgebaut...

[ralfschwalbe]

Es trifft immer mehr Kunden... Leider auch mit nicht selbst erstellter Software... Deshalb: *Push* :oops::roll:

[Luckie]

Dienstag war Patchday bei Microsoft. Kann es damit zusammenhängen?

[Uwe Raabe]

Zitat:

Zitat von Luckie (Beitrag 1455302)

Dienstag war Patchday bei Microsoft. Kann es damit zusammenhängen?

Eher nicht (Post vom 2. Januar 2020):

Zitat:

Zitat von ralfschwalbe (Beitrag 1454310)

ich habe auf manchen Windows 10 Rechnern seit ca. 14 Tagen das Problem

Vermutlich eher eines der Updates vom Dezember.

[Luckie]

Ich dachte, weil es jetzt wohl wieder vermehrt aufzutreten scheint.

[ralfschwalbe]

Vielleicht wurden die Updates etwas "verzögert" durchgeführt...

[Uwe Raabe]

Auch denkbar. Dann kann das ja schon vor Monaten eingeführt worden sein, aber wird erst jetzt wirksam.

[ralfschwalbe]

Guten Morgen,

die Probleme gehen weiter... Wo wir erst dachten, das die Angabe von

Delphi-Quellcode:

fmShareExclusive

Erlösung bringt, kommt nun der Dämpfer...

Filestreams, bei welchen die Datei bereits vorhanden ist, bringen auch bei

Delphi-Quellcode:

TFileStream.Create(FileName, fmCreate or fmShareExclusive)

den Fehler.

Intern nutzt Delphi bei Erstellen eines Filestreams mit dem Parameter

Delphi-Quellcode:

fmCreate

die Windows Funktion CreateFile. Ist die Datei vorhanden wird bei

Delphi-Quellcode:

dwCreationDisposition

der Parameter CREATE_ALWAYS, sonst CREATE_NEW benutzt.

Jetzt muss ich nur noch herausfinden, welche Änderungen sich bei UNC-Pfaden ab Dezember 2019 mittels eines Updates (auf den Clients!, der Server hat die letzten Updates um September bekommen) ergeben haben.

Haben hier andere gleiche Sorgen?

[sabba]

Hallo,

wir haben es herausgefunden. Es liegt offensichtlich an Kaspersky, zumindest hat es bisher bei zwei Kunden geholfen Kaspersky temporär zu deaktivieren.
Hier wird dieses Problem auch beschrieben:
https://www.xbaseforum.de/viewtopic.php?f=20&p=131567
https://community.kaspersky.com/kasp...ork-share-6285

[Uwe Raabe]

Wenn wir jetzt also eine Blitzumfrage unter den hier beteiligten machen, ob alle, bei denen das auftritt, auch Kaspersky im Einsatz haben und die anderen nicht, sollte das Problem identifiziert sein.

[himitsu]

Der Russe auf Client oder Server?


@ralfschwalbe
Wenn TFileStream nicht die nötigen Parameter bietet, dann nimm THandleStream+CreateFile.

Am Einfachsten in einen ClassHelper, z.B. als

Delphi-Quellcode:

class function TDeinHelper.CreateBugfix(...): TStream;

.

[sabba]

Zitat:

Zitat von himitsu (Beitrag 1455572)

Der Russe auf Client oder Server?


@ralfschwalbe
Wenn TFileStream nicht die nötigen Parameter bietet, dann nimm THandleStream+CreateFile.

Am Einfachsten in einen ClassHelper, z.B. als

Delphi-Quellcode:

class function TDeinHelper.CreateBugfix(...): TStream;

.

Wir haben den auf den Clients testweise deaktiviert.
Korrektur: Man muss es auf dem Client und Server deaktivieren.

[Uwe Raabe]

Eventuell ist dann gar kein Windows-Update, sondern eines von Kaspersky Schuld?

[ralfschwalbe]

Zitat:

Zitat von sabba (Beitrag 1455569)

Hallo,

wir haben es herausgefunden. Es liegt offensichtlich an Kaspersky, zumindest hat es bisher bei zwei Kunden geholfen Kaspersky temporär zu deaktivieren.
Hier wird dieses Problem auch beschrieben:
https://www.xbaseforum.de/viewtopic.php?f=20&p=131567
https://community.kaspersky.com/kasp...ork-share-6285

Guten Morgen,

vielen Dank. Wir werde das jetzt bei unseren Kunden prüfen und die Ergebnisse hier posten...

[ralfschwalbe]

So. Alle Sorgen-Kunden sind mit Kaspersky ausgestattet. Nach kompletter Deaktivierung ist der Fehler weg... Anfrage beim Support läuft.

Vielen Dank in die Runde! :)