Schreibschutz eines Wechselmediums auslesen

[himitsu]

Mögliche Ursachen:
* es gibt dieses Attribut bei dem getesteten Medium nicht
* dein Programm hat nicht die nötigen Rechte sowas auszulesen
* ...

Zitat:

ProcessMessages

Wozu das?

Die genannten Dateizugriffe liefern sofort eine Rückmeldung, wenn nicht geschrieben werden konnte. (Exception oder Result+Fehlercode)
Und selbst wenn man danach unabhängig nochmal nachsieht, ob die Datei da ist, dann hat ein ProcessMessages keinerlei Einfluß darauf.



Ach ja:
Das Medium ist nicht schreibgeschützt, aber über die Rechte hab ich deinem Programm verboten da reinzuschreiben.
Was nun?

[pelzig]

@himitsu:

Alles zur Schnecke machen ist recht einfach. Fällt Dir auch was Funtionierendes ein, was von Win2000 bis 8.1 und unter Wine läuft?

Ab Delphi5 oder Delphi7. Oder ab Deinem Delphi?

Für's A*loch-Karteziehen brauche ich keine Hilfe aus der DP/von Dir

MfG

Bea: "Speichere" doch mal direkt auf einem DVD-Brenner ohne ProcessMessages.

[himitsu]

Das war garnicht so böse gemeint.

War mehr als Hinweis, daß, selbst wenn du dieses Problem hier irgendwie aufwändig zum Laufen bekommst, es dir am Ende eventuell doch nichts hilft,
da es noch viele andere Dinge gibt, welche dein Vorhaben scheitern lassen könnten.
> Probleme beim Treiber, das Restesystem usw.

Ich hatte mal einen USB-Stick mit Schreibschutzschalter, den hat kein Programm erkannt, da der Zustand des Schalters nicht softwareseiteig rausgegeben wurde. Es knallte dann einfach nur beim Schreibversuch, so als wenn man in einen defekten Sektor schreiben will.



Was genau willst du denn eigentlich erreichen?




GetVolumeInformation + FILE_READ_ONLY_VOLUME

[p80286]

Zitat von himitsu:

Das Medium ist nicht schreibgeschützt, aber über die Rechte hab ich deinem Programm verboten da reinzuschreiben.
Was nun?

Da man den DAU im Auge behalten muß, ist es schon sinnvoll ihm zu sagen ob das Medium schreibgeschützt ist, oder ob die notwendigen Rechte fehlen.


Gruß
K-H

Ich hab hier einen interessanten Artikel gefunden. "Schreibschutz" ist auch nicht mehr das was ich kennen gelernt habe.

Zitat von pelzig:

@himitsu:

Alles zur Schnecke machen ist recht einfach. Fällt Dir auch was Funtionierendes ein, was von Win2000 bis 8.1 und unter Wine läuft?

Ab Delphi5 oder Delphi7. Oder ab Deinem Delphi?

Für's A*loch-Karteziehen brauche ich keine Hilfe aus der DP/von Dir

Hab ich da was verpasst?

[himitsu]

Zitat von p80286:

Da man den DAU im Auge behalten muß, ist es schon sinnvoll ihm zu sagen ob das Medium schreibgeschützt ist, oder ob die notwendigen Rechte fehlen.

Wenn es beim Schreiben knallt, sagt einem Windows schon, warum es nicht ging.

z.B. GetLastError -> ERROR_ACCESS_DENIED, ERROR_WRITE_PROTECT, ERROR_NOT_ENOUGH_MEMORY, ERROR_DISK_FULL usw.

[pelzig]

@himitsu:
Also ICH möchte nicht mit dem "WMI Delphi Code Creator" herumbasteln, wenn's nur um den Schreibschutz eines Datenträgers geht.

Der TE ist da aber eventuell anderer Meinung?

@p80286: Nö. Hast nix verpasst. Eher ich zwischen Delphi5 und XE7
@himitsu: Ich mein's auch nicht immer böse

MfG

[Truther]

@hathor Danke, jetzt wird keine Exception mehr ausgelöst. Jedoch ist der Wert False, wenn ich den Stick mit dem Schreibschutz-Schalter einstecke und das Programm ausführe. Das Problem hatte himitsu ja schon angesprochen. Es ist wohl nur von der Hardware-Seite schreibgeschützt, kann jedoch von der Software-Seite ausgelesen werden.

Woher weiß dann Windows, ob der Datenträger beschreibbar ist? Allein im Kontext-Menü fallen doch Schreib-Aktionen (Löschen, Ausschneiden) weg. Das wird doch wohl nicht alles über Exceptions laufen, oder?

Die Lösung mit GetVolumeInformation und FILE_READ_ONLY_VOLUME ist die, die mir geholfen hat.

Hier ist der Code, um diese Eigenschaft auszulesen:

Delphi-Quellcode:

function IsDriveWriteProtected(Drive: Char): Boolean;
const
  FILE_READ_ONLY_VOLUME = $00080000;
var
  Drive_Flags: DWORD;
begin
  if GetVolumeInformation(PChar(Drive + ':\'), nil, 0, nil, DWORD(nil^), Drive_Flags, nil, 0) then
  begin
    Result := ((Drive_Flags and FILE_READ_ONLY_VOLUME) = FILE_READ_ONLY_VOLUME)
  end;
end;

Hier der Code, den ich als Vorlage genommen habe: http://www.delphipraxis.net/41824-pr...formation.html

Ich danke euch allen, für eure Beiträge.

MfG
-- Truther

[himitsu]

Dein Compiler gibt nicht zufällig eine Warnung aus?
So vonwegen Result sei nicht initialisiert.

Delphi-Quellcode:

if GetVolumeInformation(...) then
  Result := Drive_Flags and FILE_READ_ONLY_VOLUME <> 0
else
  Result := False;  // <<<<<<

// oder

Result := GetVolumeInformation(...) and (Drive_Flags and FILE_READ_ONLY_VOLUME <> 0);

[Sir Rufo]

Alle die Windows für ganz schlau halten schauen sich jetzt mal die Vcl.Dialogs.TFileDialogOption an und überlegen sich, warum es hier eine Option fdoNoTestFileCreate gibt

Nach dem Auswerten der üblichen Verdächtigen, die einen Schreibschutz anzeigen, wird trotzdem eine Testdatei erzeugt um wirklich sicher zu sein, dass dort eine Datei erzeugt werden kann und man damit dort über Schreibrechte verfügt.

Und hier handelt es sich um einen gewrappten Dialog von Windows. Es ist also nicht verwerflich eine Testdatei zu erzeugen um die Schreibrechte in einem Verzeichnis zu überprüfen. Allerdings reicht ein simples CreateFile aus. Wirklich schreiben muss man da nix.

[himitsu]

Jupp, meistens ist das der einfachste Weg.


Es gibt nur gaaanz wenige und vorallem extrem seltene Sonderfälle, weswegen man das Verhalten auch deaktivieren kann.
- langsames Netzwerk, wo ein zusätzlicher Test ewig dauern kann
- WriteOnly-Berechtigungen
- ...

Letzteres kennen Einige vielleich noch, z.B. von Posteingangs-FTPs, wo man nur Schreibrechte besitzt, aber weder Löschen und vorallem nicht Lesen und meist auch nichtmal den Verzeichnisinhalt auflisten darf.
Und auch die NTFS-Berechtigungen erlauben sowas.

Blöd ist es z.B. wenn man eine Datei zum Test erstellt, Diese dann aber nicht mehr löschen oder mit den endgültigen Daten überschreiben darf.
Oder revisionssichere Datenträger, wo man Geschriebenes nicht wieder löschen/überscheiben kann.