Geöffnete Datei auf Netzlaufwerk schließen/auslesen wer darauf zugreift

Lyie

Hi,
Habe folgendes Problem.
Eine Datei liegt auf einen Netzlaufwerk. Diese Datei ist von einen anderen Nutzer im Netzlaufwerk bereits geöffnet(anderer Nutzer hat vergessen die Datei zu schließen). Kann ich iwie herausfinden welcher Rechner(Rechnername?) gerade auf diese Datei zugreif? Oder kann alle Zugriffe die auf diese Datei gerade stattfinden abbrechen, sodass auf diese Datei wieder zugegriffen/geschrieben werden kann?

Gibt es da eine Bib, Funktion in C#? Ist es überhaupt möglich? Weiß die Datei wer gerade auf sie zugreift?(Wahrscheinlich nicht.) Weiß es überhaupt jmd? Oder gibt es ein 3rd Party Programm dass mein Problem löst? Bzw. könntet ihr mir iwelche Tipps diesbezüglich geben?

Danke

Dravere

Suchst du explizit nach einer Lösung in C# oder wärst du auch an anderen Lösungen interessiert? Auf einem Windows Server (inkl. Domain und Active Directory) kann man sowas zum Beispiel mit den Windows eigenen Tools herausfinden. Ob man das über C# irgendwie abrufen kann, weiss ich nicht. Vielleicht gäbe es Möglichkeiten dies über WMI zu erreichen, aber da bin ich völlig überfragt.

hustbaer

@Dravere
Ich glaube er (sie?) möchte von einem Client PC aus rausbekommen welcher andere Client PC ein File auf einer File-Share eines Windows Servers geöffnet hat.

Und du meinst das geht echt mit Windows-eigenen Tools? Falls ja lass mich bitte wissen wie, ich wüsste nämlich nicht wie ich das anstellen könnte.

Dravere

hustbaer schrieb:

Und du meinst das geht echt mit Windows-eigenen Tools?

Kommt darauf an, was ich alles verwenden kann bezüglich "Windows-eigenen Tools". Remote Desktop Verbindung auf den File Server?

Aber auch ohne Remote Desktop Verbindung könnte es durchaus eine Lösung über WMI geben und damit über die PowerShell oder sogar C#. Meine kurze Suche hat mich zum Beispiel zu dem hier geführt:
http://powershell.com/cs/forums/t/1911.aspx

Das klingt doch eigentlich noch ganz interessant.

hustbaer

Cool.
Blöd ist dass man dazu vermutlich Adminrechte (am File Server) braucht.
Es ohne Adminrechte zu erlauben wäre allerdings wohl ein Sicherheitsloch.

Dravere

hustbaer schrieb:

Blöd ist dass man dazu vermutlich Adminrechte (am File Server) braucht.
Es ohne Adminrechte zu erlauben wäre allerdings wohl ein Sicherheitsloch.

Ja, klar. Aber solche Aufgaben werden ja üblicherweise auch von Admins durchgeführt. Bei uns käme kein Mitarbeiter auf die Idee, sowas selber zu machen, die rennen alle lieber zuerst mal zu den drei Personen, welche Admin-Rechte haben. Ich hätte mir diese nie geben lassen sollen...

Dravere

Tja, ich habe das heute auf der Arbeit ausprobiert und bin mit der oben verlinkten Lösung auf keinen grünen Zweig gekommen. Bei meiner dann weitergehenden Recherche ist mir allerdings eine äusserst einfache Lösung über den Weg gelaufen. Seit mindestens Windows XP gibt es ein Programm mit dem schönen Namen openfiles. Es erlaubt das Auflisten von offenen Dateien auf dem lokalen Computer oder einem Server. Es ermöglicht auch eine Verbindung zu unterbrechen.

openfiles /query /s myserver /u mydomain\Administrator /p /fo csv /v

Und mittels System.Diagnostics.Process ist es damit einfach in C# einbindbar.

Falls es übrigens zu Problemen kommt, weil Windows zu einem Server sich nur mit einem Konto gleichzeitig verbinden kann und daher die Verbindung über den Administrator Account fehlschlägt, kann man statt des Servernamen auch einfach die IP-Adresse angeben und das Problem damit umgehen.

Und im C# Programm dann zum Beispiel über System.Net.Dns trotzdem den Servernamen verwenden und ihn automatisch in eine IP-Adresse auflösen, bevor man es mit dem Openfiles-Programm verwendet.

hustbaer

Dravere schrieb:

Falls es übrigens zu Problemen kommt, weil Windows zu einem Server sich nur mit einem Konto gleichzeitig verbinden kann und daher die Verbindung über den Administrator Account fehlschlägt, kann man statt des Servernamen auch einfach die IP-Adresse angeben und das Problem damit umgehen.

Huch?
Ich dachte das Problem existiert nur wenn man Netzwerklaufwerke verbindet oder so.
Seit ich in meinen Programmen LogonUser(...LOGON32_LOGON_NEW_CREDENTIALS...) + ImpersonateLoggedOnUser verwende um auf Netzwerk-Shares (oder auch MSSQL Datenbanken) zuzugreifen hab' ich das Problem auf jeden Fall nicht mehr.

Ist das Utility wirklich zu doof es so zu machen dass es einfach funktioniert?

ps: Danke für die Info