Ich führe ein Node-Skript aus und erhalte unter diesem Pfad diesen Fehler:
ENOENT ../../../Library/Application Support/Google/Chrome/RunningChromeVersion
Ich kann den Fehler beheben, indem ich Chrome schließe.
Die meisten meiner Google-Suchen haben mir gezeigt, dassENORMFehler werden durch Dateien/Ordner verursacht, die nicht beendet werden.
In diesem Fall ist der Ordner jedoch eindeutig vorhanden und hängt mit der Tatsache zusammen, dass Chrome ausgeführt wird.
Ich möchte die Dateien durchsuchen können, auch wenn sie gerade verwendet werden. Ist das möglich?
Die meisten anderen Fehler werden von Apple verursacht und ich verwende einen Apple-Rechner.
ENOENT ../../../Library/Containers/com.apple..NowPlayingWidgetContainer/Daten/Dokumente/iChats
Antwort1
Der genannte Artikel RunningChromeVersionexistiert, aber es ist einsymbolischer LinkwessenZielexistiert nicht. Ihr Node-Skript behandelt Links nicht speziell, daher besteht die Standardaktion beim Versuch, sie zu öffnen, darin, dem Link zu folgen.
Das Ziel des Links existiert nicht, da er nicht auf eine Datei verweisen soll. Es handelt sich um einen Dummy-Link mit einigen nicht zugehörigen Informationen (z. B. einer Versionsnummer), die im Feld „Ziel“ gespeichert sind, wo normalerweise ein Dateiname stehen würde.
Hier ist beispielsweise das Äquivalent unter Linux (beachten Sie die lAngabe „Typ“):
$ ls -l ~/.config/chromium insgesamt 4,2 Mio. ... drwx------ 3 Grawity-Benutzer 4.0K 14. Mai 09:52 ShaderCache/ mrwxrwxrwx 1 Grawity-Benutzer 20. Mai 17 13:38 SingletonCookie-> 18396286875963223082 mrwxrwxrwx 1 Grawity-Benutzer 12. Mai 17 13:38 SingletonLock-> frost-453916 mrwxrwxrwx 1 Grawity-Benutzer 50 Mai 17 13:38 SingletonSocket-> /tmp/.org.chromium.Chromium.7Og2ow/SingletonSocket= drwx------ 3 Grawity-Benutzer 4.0K 27. Dez. 08:02 SSLErrorAssistant/ ...
Dies ist eine relativ gängige Methode zum Erstellen von „Sperrdateien“. Es ist nur ein Systemaufruf erforderlich, um einen Link automatisch zu erstellen (und es schlägt fehl, wenn er bereits vorhanden ist), ein Systemaufruf, um seinen „Inhalt“ (das Feld „Ziel“) zu lesen, und ich glaube, es ist sogar NFS-/SMB-/AFS-kompatibel, während tatsächliche Dateisperren bei diesen Netzwerkdateisystemen tendenziell weniger gut funktionieren.
Wenn Sie readdir() zum Scannen von Verzeichnissen verwenden, enthält jeder Verzeichniseintrag bereits Informationen über seinen Typ: In Node können Sie beispielsweise Folgendes aufrufen:.isSymbolicLink()bei jedem Readdir-Ergebnis.
Wenn Sie nur den Pfad haben, können Sie das Node-Äquivalent deslstat()Funktion zum Überprüfen, ob ein Pfad ein symbolischer Link ist, und zum Vermeiden, ihn auf diese Weise zu durchlaufen ( readlink()bei Bedarf kann auch das Feld „Ziel“ gelesen werden).
Es ist eigentlichempfohlenum symbolische Links bei der rekursiven Dateisuche zu überspringen, da das Befolgen symbolischer Links zu einer Endlosschleife führen kann (z. B. zeigt dirA/linkB auf ../dirB, aber dirB/linkA zeigt auf ../dirA, und jetzt stecken Sie fest).