Fehlermeldung/Error message "File is not writable“

[wolboe]

Die Kamera des Samsung Galaxy S10 bietet für  Motive, die viel Text enthalten, zwei Möglichkeiten, ein Bild zu erzeugen:
1.   Ein normales Foto
2.   Scanmodus – nur der Textteil wird erfaßt
In beiden Fällen erhält man eine jpg-Datei.
Die Metadaten der Datei zu 1. können wie erwartet gehandhabt werden.
Ändert man in den Metadaten z. B. die Beschreibung, gibt es aber bei der Datei zu 2. die Fehlermeldung "File is not writable"
(Text im Beispielbild ist bedeutungslos).

Was ist an dieser Datei nicht in Ordnung?

The camera of the Samsung Galaxy S10 offers two ways to create an image for subjects that contain a lot of text:
1. a normal photo
2. scan mode - only the text part is captured.
In both cases, you get a jpg file.
The metadata of the file for 1. can be handled as expected.
However, if you change the metadata, e.g. the description, you will get the error message "File is not writable" for file 2.
(Text in the example picture is meaningless).

What is wrong with this file?

Wolfgang

(Translated with www.DeepL.com/Translator (free version)

[Mario]

Wo bekommst Du die Fehlermeldung?

Ich habe die Datei runtergeladen, einige Metadaten eingetragen und dann rückgeschrieben. Keine Probleme.
Vielleicht war die Datei noch in einer anderen Anwendung offen?

[wolboe]

Sorry Mario,
da fehlte ein Bild im Upload - hänge das fehlerhafte jetzt hier an.
Das von Dir benutzte Bild war/ist ok.

Wolfgang

[Mario]

Auch keine Probleme mit dieser Datei.
Rating, Label, Description wurden problemlos geschrieben und stehen auch in der Datei drin.
ExifTool meldet keine Probleme.

Metadata Anaylst app zeigt auch nichts dramatisches für beide Dateien.

[wolboe]

Eigenartig.
Verhalten ist bei mir reproduzierbar und schon mehrfach aufgetreten - aber immer nur bei den Dateien, die im Scanmodus aufgenommen wurden.
Habe jetzt beide von mir hochgeladenen Bilder wieder runtergeladen, in anderem Verzeichnis unter gleichgem Namen abgelegt - alles wie gehabt, die eine ist ok, die andere zeigt die Fehlermeldung.

Letzter Versuch.
In der zip-Anlage sind die gespeicherten Daten von Metadata Analyst von beiden Bildern (....155995.json ist die vom fehlerhaften Bild). Vielleicht erkennts Du da etwas.
Ansonsten - schade um die Zeit. Die einfachste Lösung für mich war in solchen Fällen immer, die Datei in einem anderem Programm unter neuen Namen zu speichern.

Wolfgang

[wolboe]

Noch ein Nachtrag:
Wenn man in Exiftool versucht, die XMP-Metadaten zu löschen, kommt folgende Aussage:
Warning: [minor] Entries in IFD0 were out of sequence. Fixed. - C:/Eigene Bilder/AAA_neue Bilder/_Henry/scanmodus_20220713_200948.jpg
    0 image files updated
    1 image files unchanged

[Mario]

Bitte nicht die ganzen JSON-Daten anhängen. Nur die Fehler und Warnungen mit dem GRÜNEN KNOPF oben im MDA in die Zwischenablage kopieren und in den Post einfügen.
Sich durch tausende Zeilen JSON wühlen ist eine Strafarbeit.

Ich kann Problem mit den von Dir bereitgestellten Dateien nicht nachvollziehen.
Ich habe die XMP-Daten mit dem "Delete XMP Metadata" Preset m ExifTool Command Processor gelöscht. Meldung "1 image files updated", für beide Dateien!
Mehr kann ich nicht tun.

Vielleicht kann ein anderer Anwender Deine Dateien runterladen, ein paar Daten ändern und dann rückschreiben.

[sinus]

Vielleicht kann ein anderer Anwender Deine Dateien runterladen, ein paar Daten ändern und dann rückschreiben.

Ich habe die zweite Datei runtergeladen, importiert, dann Headline/Description geändert und bekomme die Meldung wie im Attachement.

Und im log steht das:

Code Select Expand

07.15 09:07:41+ 1859 [1CF0] 01  W> ETWARN: Writeback: File not writable: D:\_temp-files_send_usw\1_kopiert-zum-senden\scanmodus_20220713_200948.jpg  'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(3329)'

Ich habe ab und zu solche Dateien gehabt, aber selten.
Mich hat das jeweils nicht gekümmert, weil ich die entweder einfach gelöscht habe oder allenfalls in Photoshop geändert, bis es klappte.
Ich fand einfach die Zeit zu schade, deshalb habe ich da nie genau geschaut. 

[wolboe]

Markus hat recht - die Zeit ist zu schade, um die Ursachensuche zu vertiefen.
Trotzdem Dank für das Interesse.

Wolfgang

[Mario]

Ich habe die Datei nochmal runtergeladen (Link speichern unter...), in eine Datenbank aufgenommen, headline und description im MD panel geändert und mit dem Pen zurückgeschrieben.
ExifTool meldet:

E:\data\download\community\12618\scanmodus_20220713_200948.jpg
-execute9999
    1 image files updated
    1 image files updated
----- Runtime: 1 s.

Die von mir eingegebenen Daten sind auch in der Datei zu sehen (in IMatch und in ECP).
Keine Ahnung, was ich anders mache...

[hluxem]

This reminded me of a problem with write back I have seen for years, mostly with scanned pictures.
When I have the Quick View panel open and initiate a write back, some files show the write back error. I have never been able to reproduce this reliable and now just close the Quick Viewer when I work with scanned images. I think I even posted that issue some years ago.

I downloaded the sample picture and with the Quick View panel open I see the write back error. Write back works fine with the Quick View panel closed.

Maybe Wolfgang or Sinus can check out if they see the same effect.

Heiner

 

[Mario]

Good suggestion.

The Quick View panel loads cache images (or the original file in this case, since this is a JPG) via Windows WIC. Once loaded, IMatch closes the file again, so there should be no file locking or anything that's preventing ExifTool from writing to the file. I've just tried that and the file was written without problems while being displayed in the Quick View Panel.

Anyways, that being said, Windows sometimes works in mysterious ways, an installed virus checker may become somehow involved, maybe a Windows Explorer window is open for the folder and Windows decides to create a thumbnail cache entry for the file just at the same time ExifTool is writing to it...or one of two dozen other potential things that may go wrong.

[wolboe]

Maybe Wolfgang or Sinus can check out if they see the same effect.

Ich habe es probiert - Das ist die Lösung! Das Quick View panel ist bei mir immer auf dem zweiten Monitor geöffnet.
Danke für den Hinweis.

I have tried it - this is the solution! The Quick View panel is always open on the second monitor.
Thanks for the tip.

Wolfgang

[sinus]

Cool, Heiner, good idea.

And since Wolfgang tried it and he found the same, what you have seen, we have, I think, the solution!

Very good, having such a great user-forum. 

[Mario]

In diesem Fall sollte im log file aber folgendes stehen:

ETWARN: Writeback: File not writable:

Vor dem Rückschreiben prüft IMatch, ob die Zieldatei beschreibbar geöffnet werden kann.
Das testet Dinge wie read-only Attribute gesetzt, read-only Datenträger, unzureichende Berechtigungen des Benutzers und Datei von anderer Anwendung exklusiv geöffnet (also gelockt).

Im Fall der JPEG-Datei, die im "scan modus" erstellt wurde, liefert diese Testfunktion "nicht beschreibbar" zurück, wenn die JPG-Datei im QuickView-Panel geöffnet ist.
Meine Vermutung ist wohl, das die Datei irgendwie "nicht standard" ist und Windows WIC die Datei nach dem Lesen aus irgend einem Grund geöffnet hält.

Erst wenn ich das Quick View Panel schließe und somit alle im Speicher gecachten Dateien freigebe und quasi WIC "runterfahre", kann ich die "scan"-Datei schreiben. Bei der anderen JPEG-Datei geht das immer, auch wenn die Datei gerade im Quick View Panel angezeigt wird. Von IMatch-Seite aus ist der Code aber immer der gleiche, es muss also an Windows WIC liegen, und am Inhalt der Datei.

Da lohnt sich keine weitere Untersuchung, denke ich.

[Mario]

OK, es ist definitiv ein Problem in Windows WIC oder dem Codec, der zum Laden der JPEG-Datei verwendet wird.

Für die "scan mode"-Datei hält Windows ein lock auf die Datei, auch wenn IMatch intern alles ordnungsgemäß schließt und freigibt!
Es scheint aber ein sehr seltenes Problem zu sein, denn ich konnte genau einen (!) Report (von 2018) über dieses Problem bei Google finden.

In dem Report wurde auch ein work-around beschrieben. Wenn man das Öffnen der Datei nicht Windows/WIC überlässt, sondern die Datei selbst öffnet und danach WIC das Handle der Datei übergibt, wird das Lock nicht gehalten. Ich habe das mal testweise implementiert, und in der Tat löst dies das Problem. Wenn IMatch die Datei selbst öffnet und auch wieder schließt, bleibt sie nicht gelockt und ExifTool kann rückschreiben.
Das betrifft aber nur die "scan mode"-Datei, die andere JPEG-Datei hat das Problem ja nicht.

Da es aber dann- und wann mal Reports über ähnliche Probleme gab (im Zusammenhand mit Quick View und Schreiben), werde ich das neue Verfahren wohl am besten fest einbauen, und diese Probleme umgehen. Es kann auch den Viewer treffen, wenn der Anwender den Viewer offen hat, während er Dateien rückschreiben lässt, und diese Dateien im Viewer geöffnet wurden.

[ubacher]

Ich habe des öfteren Probleme beim Löschen oder umbenennen von Dateien und wenn ich dann
Quickview schließe funktioniert es. Aber das ist nicht beschränkt auf eingescannte Dateien.

[Mario]

Könnte die gleiche Ursache haben.
Wenn WIC nach dem Schließen ein exklusives Lock auf eine Datei hält, kann sie nicht von anderen Anwendungen beschrieben, verschoben oder gelöscht werden.
Das Problem liegt nicht bei IMatch, sondern in WIC selbst. Und sollte nur JPEG-Dateien betreffen, alle anderen Dateien werden ja aus dem IMatch-Cache geladen.
Der Work-around sollte auch in Deinem Fall helfen, vermute ich mal.

Ich habe das fest eingebaut, getestet und in einer Release Note dokumentiert.

[wolboe]

Es freut mich, dass Mario wieder etwas klären konnte, was sonst sicher vereinzelt immer mal wieder zu erneuten Anfragen hätte führen können.
Wolfgang