Exception bei FileInfo.Open

[FwDonnerbalken]

Hallo zusammen,

ich google mir bereits den Vormittag lang die Finger wund und versuche es jetzt hier gezielt mit meiner Frage.

Folgendes Problem, welches sich leider auf meiner Testmaschine nicht reproduzieren lässt und auf das Produktivsystem habe ich keinen Zugriff.

Bei der Ausführung folgenden Codes (bei fi.Open()) kommt es zu einer Ausnahme. Der Benutzer verfügt über "Vollzugriff"s-Rechte. Dateimanipulationen jeglicher Art sind mit anderen Programmen und dem Windows-Explorer möglich.

var fi = new FileInfo(path);
if (!fi.Exists)
  return false;

stream = fi.Open(FileMode.Open, FileAccess.ReadWrite, FileShare.None);

Exception: Access to the path 'E:\Document Database\images\bf\RA100\1\13.tif' is denied.

StackTrace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at System.IO.FileInfpen(FileMode mode, FileAccess access, FileShare share)

Interessanterweise schreibt mir mein Kunde, dass wenn er ALLE Dateieigenschaften und Attribute entfernt, die Dateien verarbeitet werden. Ich vermute allerdings, dass dies nur ein zufälliger Seiteneffekt ist. Probleme mit dem ReadOnly Attribut scheint es nämlich nicht zu geben.

Grundsätzlich sei noch angemerkt: Die Dateien wurden von einer CD auf ein lokales Laufwerk kopiert. Das Laufwerk von dem gelesen wird ist kein Netzlaufwerk.

Die Anwendung verwendet das .NET Framework 4, läuft als x86. Verwendete Dll's verwenden keine starken Namen, wurden allerdings signiert.

Ich kann einfach keine brauchbaren Ressourcen im Netz finden die mir weiterhelfen.

Danke für eure Mithilfe.

 

[Spyke]

Ganz blöd.
Kann es sein das es im RA100 Ordner einen unter Ordner "13.tif" noch gibt und es dadurch zu Problemen kommen kann?
Immerhin sagt ja die Meldung "Access to the path".

 

[FwDonnerbalken]

Hi Spyke,

Nein, da ist definitiv kein Ordner der 13.tif heißt. Falls dies der Fall wäre würde die Exception auch anders lauten. Ich hab's noch nie getestet, aber ich denke ich kann keine Datei und Ordner mit exakt dem selben Namen nebeneinander haben. Und wäre die Datei jetzt ein Ordner wäre fi.Exists ja schon ausgestiegen.

Desweiteren gehe ich in diesem Fall davon aus, dass der gesamte Pfad zur Datei mit 'path' gemeint ist.

 

[DimpiM]

Probiers mal ohne der FileShare Überlagerung.
Evtl. hat ein anderer Prozess die Datei noch geöffnet

 

[FwDonnerbalken]

Probiers mal ohne der FileShare Überlagerung

Guter Hinweis, wird aber leider nicht helfen. Der Aufruf ohne FileShare ist genauso gut wie der Aufruf mit. Der Default Wert der anderen Überladung ist ebenfalls FileShare.None.

Evtl. hat ein anderer Prozess die Datei noch geöffnet

Laut MSDN würde in diesem Fall eine IOException geworfen. Diese habe ich allerdings explizit gefangen. (Was aus dem Code oben nicht ersichtlich ist)
Siehe: http://msdn.microsoft.com/de-de/library/vstudio/d3wke8tz(v=vs.100).aspx


Generell müsste ich mal den Fall der UnauthorizedAccessException -> path ist schreibgeschützt oder ein Verzeichnis. prüfen. Allerdings passt das generelle Verhalten, nämlich das einige Dateien verarbeitet werden und andere nicht, nicht in das Verhalten des Codes.

Schauen wir uns mal die Möglichen Ausnahmen von FileInfpen() an:

Exception	Bedingung	Kommentar
SecurityException	Der Aufrufer verfügt nicht über die erforderliche Berechtigung.	Dies würde auf das Verhalten der Anwendung passen, allerdings wundert es mich aufgrund des Vollzugriffs
ArgumentException	path ist leer oder enthält nur Leerräume.	Nicht der Fall
ArgumentNullException	path ist leer oder enthält nur Leerräume.	Nicht der Fall
FileNotFoundException	Die Datei wurde nicht gefunden.	Nicht der Fall, eine vorherige Prüfung schließt diese Exception aus.
UnauthorizedAccessException	path ist schreibgeschützt oder ein Verzeichnis.	Wäre evtl. denkbar. Siehe jedoch oben, es wurden ja einige Dateien verarbeitet
DirectoryNotFoundException	Der angegebene Pfad ist ungültig. Dies ist z. B. der Fall, wenn das Laufwerk des Pfades nicht zugeordnet ist.	Nicht der Fall, die Datei existiert und dementsprechend auch der gesamte Pfad.
IOException	Die Datei ist bereits geöffnet.	Nicht der Fall, wird explizit gefangen und würde in der Verhalten des Codes passen.

 

[deepthroat]

Hi.

Welche Exception wird denn nun genau geworfen?

Welchen Wert hat die IsReadOnly Property von fi?

 

[saftmeister]

Schon an den Index-Dienst von Windows gedacht und ggf. mal mit Abschalten oder Ausnahme des Ordner, in dem die Datei liegt, versucht?

 

[FwDonnerbalken]

Welche Exception wird denn nun genau geworfen?
Welchen Wert hat die IsReadOnly Property von fi?

ReadOnly ist false. Die Exception ist eine UnauthorizedAccessException.

Schon an den Index-Dienst von Windows gedacht und ggf. mal mit Abschalten oder Ausnahme des Ordner, in dem die Datei liegt, versucht?

Nein, aber dem werde ich mal nachgehen.
Edit: Sperrt der Indexdienst die Dateien in irgendeiner Form? Ich hatte schon an Antivirensoftware gedacht... ?!

 

[Spyke]

Brauchst du auch unbedingt schreibrechte auf die Datei oder würde nicht auch lesen reichen?

 

[FwDonnerbalken]

Jaein. Nachdem das Programm die Datei verarbeitet hat muss/kann diese verschoben werden.
In diesem Fall geht es konkret darum festzustellen ob die Datei noch in Benutzung ist. Daher der Versuch diese mit Schreibrechten zu öffnen. In paar Zeilen tiefer in der original Methode wird außerdem noch geprüft um sich die Dateigröße verändert. Damit fange ich die Möglichkeit ab, dass ein Programm Stück für Stück Daten an die Datei anhängt. (passiert z.B. bei manchen Scannern / Kopierern)
Daher fange ich auch nur die IOException und lasse alle anderen Ausnahmen unbehandelt durch.

Falls du oder jemand anders eine bessere Methode hat festzustellen ob eine Datei durch andere Prozesse verwendet wird... immer her damit.