ShellExecute und schreibgeschütztes Medium

[Poolspieler]

Hallo,
ich würde mit folgendem Code gern ein externes Programm starten:

Code:

ShellExecute(Application.Handle, 'open', PChar(_datei), PChar(_parameter), Nil, SW_ShowNormal);

Dies funktioniert auch problemlos.

ABER:
Wenn das AUSZUFÜHRENDE Programm auf einem schreibgeschützten Medium (in meinem Fall eine SD-Karte) liegt, dann bekomme ich NUR unter WinXP folgende fehlermeldung von Windows (der Rückgabewert ShellExecute ist OK!):

Zitat:

Der Datenträger ist schreibgeschützt und kann nicht beschrieben werden. Entfernen Sie den Schreibschutz vom Datenträger in Laufwerk D:.

Das ganze tritt unter Win7 NICHT auf.

Ich habe es auch schon mit ShellExecuteEx ausprobiert --> gleiches Ergebnis.

Warum glaubt WinXP, ShellExecute wolle irgendwo schreibend zugreifen? Ich habe auch schon die notepad.exe mal auf das schreibgeschützte, und mal auf z.B. C:\ gelegt. --> Auf dem schreibgeschützten Verzeichnis bekomme ich die Fehlermeldung - auf C:\ nicht.
--> führe ich die Datei direkt aus (also nicht über ShellExecute, sondern über den Dateiexplorer), dann kommt KEIN Fehler. Es liegt also DEFINITIV am ShellExecute-Aufruf.

Ich versteh die Welt nicht mehr

Hat jemand eine Idee?

Viele Grüße,

Poolspieler

[himitsu]

Was für eine Datei willst du öffnen und mit welchem Programm ist sie verknüpft?

Einige Programme öffnen Dateien nicht nur ReadOlny oder sie erstellen gerne mal im Verzeichnis der zu öffnenden Datei eine temporäre Hilfsdatei.
> also Schreibzugriffe

Unter Windows 7 könnte da eventuell die Virtualisierung für schlechte/alte Programme zuschlagen.

[Poolspieler]

Hi,
danke für Deine Antwort!

Eigentlich will ich ein von mir geschriebenes Delphi-Programm öffnen.
Oder ein mit Innosetup erzeugtes setup.exe.
Ich habe es aber auch mit der notepad.exe aus WinXP versucht.

--> bei allen Programmen ist es das selbe Problem.

Gruß,

Poolspieler

[Poolspieler]

Hallo,
ich habe eine weiter Erkenntnis:

Das Problem tritt NUR bei SCHREIBGESCHÜTZTEN SD-Karten auf!
--> Bei einer gebrannten CD tritt das Problem NICHT auf.

Vielleicht sind hier die SD-Karten ein magischer Sonderfall und ich sollte diesen im Kleingedruckten der Software-Beschreibung einfach ausschließen...

Aber vielleicht hat ja jemand noch eine bessere Idee...

Viele Grüße,

Poolspieler

[WM_CLOSE]

Ich habe mal einen Filesystem Treiber geschrieben, in den Dokus stand etwas von Dateisystemtypen.
Der CDFS-Treiber hat zum beispiel keine Funktionen zum Schreiben ind ist auch so gekennzeichnet.

Die SD-Karte ist vermutlich FAT32 oder NTFS formatiert, also mit Schreibfunktion, welche nur durch den Schalter an der Karte selbst unterdrückt wird.

PS: versuch es mal mit CreateProcess

[himitsu]

Bei NTFS wird z.B. das Datum/Uhrzeit des letzten Dateizugriffs gespeichert
und ich glaub im Windows 7-Treiber wurde dieses Verhalten wieder geändert.

Man braucht also nur eine Datei zu öffnen und es geschieht ein Schreibzugriff.


Zusammen mit der Aussage von WM_CLOSE (ups, jetzt ist mein Browser weg) könnte es da schon die Auswirkungen erklären.

[WM_CLOSE]

Nochmal zur Erlklärung: Treiber sind im Grunde wie Klassen, die ein Interface implementieren.

zur Veranschauichung nehmen wir die Interfaces
IWritableFS
{
procedure WrieFile(...);
...
}
und
IReadableFS
{
procedure ReadFile(...);
}

NTFS implementiert beide Interfaces,
CDFS nur IReadableFS

Damit weiß Windows, ob es auf einem bestimmten FS schreiben kann.

Jetzt kommt die NTFS? formatierte SD-Karte. Windows sieht: NTFS->beschreibbar.
Aber die SD-Karte macht mit dem lock einen Strich durch die Rechnung.

Im Vista/7 Treiber für die SD-Karten wurde das problem scheinbar umgangen, indem die tatsächliche Beschreibbarkeit geprüft wird.

Mit CreateProcess müsste es eig. trotzdem gehen.

[himitsu]

Mir fällt auch grade ein, daß ich unter Windows 7 diesbezüglich auch noch keine Probleme bemerkt hab,
auch nicht bei USB-Sticks mit Schreibschutz, egal ob FAT32, ExtFAT oder NTFS.

(bei SD-Karten war ich noch nicht auf die Idee gekommen diese mit NTFS zu beschreiben, da die andere Hardware es eh nie verstanden hätte)


Eventuell solltest du es dann auch nochmal mit solchen USB-Sticks probieren, welche ebenfalls einen Schreibschutzschalter besitzen.



PS: Bei USB wird der Schreibschutz über den Controlerchip im USB-Stick geregelt (den man nur im abgezogenen Zustand umschalten sollte/darf) und je nach dem was dort für ein mistiger Controler verbaut wurde, teilt er dem Dateisystemtreiber ordnungsgemäß mit, ob dieses Medium beschreibbar ist.

Bei den SD-Karten drückt dieser Schalter einen Kontakt im Lesegerät, womit dann natürlich das Lesegerät darauf reagieren muß.
Es könnte also auch sein, daß einige Billiggeräte nicht drauf reagieren, bzw. es erklärt auch, warum einige zu straffe Kontakte gerne mal diesen Schalter beim Einschieben umstellen, was ich mal bei einer Fotokamera hatte.

[Poolspieler]

Hallo Zusammen,
ich habe nochmal einige (viele) Tests gemacht.

Ergebnisse:
1. Das Problem tritt auch bei schreibgeschützten USB-Sticks auf
2. Ich habe zwei SD-Reader getestet
- einen im Laptop (Samsung) integrierten
- einen externen (getestet unter Win7 und WinXP)
--> bei beiden Readern ist das selbe Verhalten vorhanden
3. ich habe Freund Procmon mal mitlaufen lassen
--> himitsu hat recht. Es wird zuerst ein QueryBasicInformationFile und anschliessend SetBasicInformationFile durchgeführt. Bei SetBAsicInformationFile(CreationTime, LastAccessTime, etc.) kommt der Fehler
4. CreateProcess habe ich versucht, da bekomme ich aber viele Fehler - wahrscheinlich rufe ich den Befehl noch mit falschen Parametern auf - das werde ich im Forum aber mal nachlesen...


Viele Grüße,

Poolspieler

[himitsu]

Es gibt für's NTFS scheinbar einen eine Einstellungsmöglichkeit, wo man solche Schreibaktionen deaktivieren kann.
Aber wie und wo, das weiß ich auch nicht.

Das ist mir mal untergekommen, beim Thema Windows auf Flash-Disk (noch vor den SSD, wo man eine Flash-Karte via IDE angeschlossen hat), oder als Live-System auf USB-Disk laufen zu lassen.
Da diese Speicher eine begrenzte Lebensdauer haben/hatten, was das Beschreiben betrifft, wurde damals irgendein "Hack" verwendet, welcher eben Jenes verhinderte.