Temporäre Dateien in AppData

Hallo!
Wir haben ein Update von LL 17 auf LL 21 durchgeführt und nun Probleme mit Zugriffsfehlern auf temporäre Dateien durch die Windows Benutzerkontensteuerung.

Bei einigen Kunden z.B. unter Windows 7 Prof. verhindert die Benutzerkontensteuerung von einen Tag auf den anderen Tag den Zugriff auf den temporären combit Ordner, den LL 21 für die Vorschau und den Druck unter [b]c:\Users\USER\AppData\Local\Temp\combit[/b] anlegt um temporäre Dateien abzulegen. Dieses Verhalten gab es unter LL 17 nicht.

Inhalt des Ordners siehe Anhang.

Wir setzen im Source bereits den Temp-Pfad mit LlPreviewSetTempPath, LlSetPrinterDefaultsDir indem die .LL, .lsp und .lst usw. gespeichert wird.

In der Dokumentation können wir keine entsprechenden Infos finden, wie der Pfad ggf. umgebogen werden kann, bzw. warum diese Dateien mit LL21 überhaupt erzeugt werden.

Kennt jemand das Problem?

Gruß S. Ingwersen

combit-Ordner.JPG

Hallo Herr Ingwersen,

vielen Dank für Ihren Beitrag.

List & Label verwendet diesen Pfad seit LL18 und legt hier die für den Druck temporär benötigten Dateien ab. Nach dem erfolgreichen Druckvorgang werden die Dateien wieder gelöscht. Das Temp-Verzeichnis des Windows-Benutzers (Start > Ausführen > %temp%) wird verwendet, da Schreib- und Lese-Rechte benötigt werden. Der Pfad kann LL-seitig nicht geändert werden.

Mit freundlichen Grüßen

Christian Rauchfuß
Technischer Support
combit GmbH

Wir verwenden LL27 und haben jetzt auch vermehrt Kunden wo beim Drucken die Anwendung abstürzt hängt.
Unsere Analyse hat ergeben, dass LL nicht mehr auf das Verzeichnis “C:\Users\<User>\AppData\Local\Temp\combit\” zugreifen kann.
Nachdem wir dem Account wieder volle Zugriffsrechte auf “C:\Users\<User>\AppData\Local\Temp” gegeben haben, ging der Druck wieder.

So wie ich es verstehe, ist es bei einem Kunden kurz drauf wieder aufgetreten.

Ich habe mal im Internet gesucht und zwei Fälle von 2021 und 2020 gefunden, wo sich Leute beschweren, dass die regelmäßig Zugriff auf “AppData\Local\Temp” verlieren:

In einem älteren Artikel von 2013 lag es an Adobe Acrobat Pro XI: https://forums.tomshardware.com/threads/temp-folder-writing-permission-by-itself.1313478/

Dort ist auch ein Verweis auf einen Microsoft Forums-Beitrag von 2012 wo es ebenfalls an Adobe Acrobat 11 lag: https://answers.microsoft.com/en-us/windows/forum/all/cant-install-any-applications/7fc00c13-c91e-4288-99f3-133f957930c2

Mich würde wundern, wenn Adobe das in den letzten 12 Jahren nicht behoben hat, aber einer unserer Kunden hat bestätigt, dass er demletzt Acrobat Reader installiert oder aktualisiert hat.

Ich weiß auch nicht, ob der Absturz der Anwendung in List&Label verursacht wurde oder von unserem nachfolgendem Code.
UPDATE 02.10.2024: Die Software stürzt nicht ab, sondern hängt für immer im List&Label Code.

Aber vielleicht sollte Combit eine MessageBox einbauen, welche darauf hinweist, dass auf “C:\Users\<User>\AppData\Local\Temp\combit\” nicht zugegriffen werden kann und die Benutzerrechte bei dem Verzeichnis geprüft werden sollen.

1 Like

Danke für den Hinweis, höre ich zum ersten Mal. Wir könnten das zumindest prominent im Logfile ausgeben. Ich werde mir das morgen mal genauer ansehen.

Im Debwin4-Protokoll sind bereits Einträge:

LL.Generic;4900;100:2=CMUT27?101:1=3;[clsTempFileRemover] cannot create/open activity file ‘C:\Users\s3000\AppData\Local\Temp\combit_27_activity.signal’: Zugriff verweigert (00000005)

Aber die Software sollte nicht abstürzen. Aber wie bereits erwähnt, weiß ich nicht, ob der Absturz in List&Label oder in unserem Code der nach dem Drucken folgt passiert.

Ich habe gestern auch zwei Kunden-Calls bearbeitet, wo das Problem auftrat.

Beide Kunden haben so um die fünf bis sieben Rechner und das Problem trat jeweils nur auf einem Windows 11 Rechner auf. Ein paar Tage zuvor wurde auf diesem Rechner einiges an Software installiert (unter anderem auch Acrobat Reader).

Ich habe mit unserer Software das Erstellen einer Vorschau mit List&Label getestet.
Also die Anwendung stürzt nicht ab, sondern hängt und reagiert nicht mehr.
Ich habe ein Dump-File mit dem Task-Manager erstellt und dort kann ich sehen, dass wir als letztes LlPrint() aufgerufen haben und auf dessen Rückkehr warten.
Im Task-Manager war mir auch aufgefallen, dass die CPU-Auslastung für unsere Anwendung bei 24-25% war.

Mit dem Explorer konnte ich auf “C:\Users\s3000\AppData\Local\Temp” zugreifen (ich weiß nicht, ob da schon jemand anderes die Zugriffsrechte wieder gesetzt hatte).
Aber als ich mit dem Explorer “C:\Users\s3000\AppData\Local\Temp\combit” öffnen wollte, bekam ich folgende Meldung:

Nachdem ich dort “Fortsetzen” geklickt hatte, funktionierte das Erstellen einer Vorschau und auch der Druck wieder ohne Probleme.

Wir verwenden momentan List&Label Version 27 SP2 plus zwei Fixe, wollen aber Anfang nächsten Jahres die Kunden auf Version 29 SP3 umstellen.

Es ist nicht Combits Fehler, dass irgendwas (wahrscheinlich eine andere Softwareinstallation) dem Benutzer die Zugriffsrechte auf sein eigenes Temp-Verzeichnis "C:\Users\<Benutzer>\AppData\Local\Temp" entzieht.
@jbartlau Aber vielleicht könnte Combit testen wie List&Label reagiert, wenn es keine Zugriffsrechte auf das Temp-Verzeichnis “C:\Users\<Benutzer>\AppData\Local\Temp\combit” hat.
Idealerweise sollte List&Label weder abstürzen, noch für immer hängen, sondern einen Fehlercode zurückgeben.

1 Like

Wir werden uns das - voraussichtlich für Version 30.001 - einmal ansehen. Will heißen bei mir geht es schon:

EXCEPTION(ERROR: insufficient rights on temp path 'C:\Users\xxx\AppData\Local\Temp\combit\' (Zugriff verweigert (00000005))
...
<LlPrintEnd() -> -12 (FFFFFFF4) (Während des Druckens ist ein allgemeiner Fehler aufgetreten. Prüfen Sie die Projektdatei und die Datenquelle.)

Die Änderung ist allerdings etwas größer und wir sind bereits in der Codefreeze-Phase für Version 30. Daher werden wir das nicht mehr in den Release-Branch mergen. Vielen Dank noch einmal für den Hinweis.

1 Like

Sehe ich das richtig, dass momentan Fehlercode -12 “Während des Druckens ist ein allgemeiner Fehler aufgetreten. Prüfen Sie die Projektdatei und die Datenquelle.” geplant ist? Oder war das nur zum Testen/Proof of Concept?

Wäre es möglich einen eigenen Fehlercode für unzureichende Zugriffsrechte auf “C:\Users**\AppData\Local\Temp\combit” zu haben?

Dann könnten wir den Fehler nämlich anzeigen und der Support wüsste sofort was zu machen ist.

Das ist leider nicht so einfach - der Fehler kann sehr weit “unten” auftreten, weswegen jetzt eine C++ Exception geworfen wird, die ganz “oben” gefangen wird. Im Logfile ist das Problem im Klartext aufgeführt, einen eigenen Fehlercode hat es aber nicht bekommen.