Es geht nur um Dateiberechtigungen: Wenn die Engine die Rechte hat, sie zu löschen, funktioniert es; wenn sie keine Rechte hat, kann sie sie nicht löschen (Windows meldet einen Fehler, falls ein Löschvorgang fehlschlägt).
Das Protokoll besagt, dass es gelöscht wurde, aber es wurde nicht gelöscht.
Wo sollte dieser Fehler protokolliert werden, wenn Windows nicht angibt, was das Problem war?
Wie ich oben sagte, wird kein Fehler protokolliert, da Windows keine Fehler meldet, wenn ein Löschvorgang fehlschlägt. Es wird einfach nicht gelöscht.
Die Protokolle sagen „Lösche Datei xxxx“, es sendet den Befehl zum Löschen, aber wenn Windows sie nicht löschen kann, meldet es nichts zurück, daher siehst du keine Fehler.
Alles klar, mein Fehler, ich habe es missverstanden.
Ich werde versuchen, benutzerdefinierte Befehle hinzuzufügen, um die Quelldatei mit cmd zu löschen.
Das wird wahrscheinlich auch nicht funktionieren, da die benutzerdefinierten Befehle mit denselben Berechtigungen wie die mcebuddy-Engine ausgeführt werden. Ich würde vorschlagen, zunächst die Berechtigungen für den Zielordner/Temp-Ordner auf „Jeder“ zu setzen und dann schrittweise einzuschränken, um festzustellen, wo das Problem liegt. Stelle außerdem sicher, dass die Dateisystemverschlüsselung deaktiviert ist.
Ja, für das gesamte Laufwerk ist die Berechtigung auf „Jeder“ > „Vollzugriff“ gesetzt…
Temp-Ordner bedeutet das Arbeitsverzeichnis von MCEBuddy?
Der Dienst wird als Administrator ausgeführt.
Das sollte sicherstellen, dass für alle diese Dateien die entsprechenden Berechtigungen vorhanden sind.
Ja
Die andere Möglichkeit könnte sein, dass ein anderer Prozess oder ein anderes Programm die Datei gesperrt hat und MCEBuddy dadurch am Löschen hindert (ein recht häufiges Problem, wenn man im Forum sucht – etwa ein Antivirenprogramm oder ein Überwachungsprogramm).
Das würde erklären, warum es manchmal funktioniert und manchmal nicht.
Tatsächlich war beim letzten Mal ein Prozess, der die Datei gesperrt hat, als ich sie ausgeführt habe, und es ist fehlgeschlagen. Dann habe ich es erneut ausgeführt und im Systemmonitor überprüft, was auf die Datei zugreift. Natürlich gab es dann keinen Zugriff mehr.
Ich versuche es jetzt noch einmal und prüfe erneut, ob etwas ist.
Ich bin auf Windows Server 2016 ohne Antivirus. Ich habe keine Überwachung, aber mein Receiver greift auf den Pfad zu, weil er die Dateien dort aufzeichnet, aber das sollte keine Dateien sperren…
Nur damit du Bescheid weißt:
Wenn ich
CustomCommandPath="C:\Windows\System32\cmd.exe"
CustomCommandParameters="/c del /f /q "%sourcefile%""
CustomCommandHangPeriod=100
CustomCommandCritical=true
CustomCommandUISession=false
CustomCommandShowWindow=false
meinen Profilen hinzufüge, werden die Aufträge abgeschlossen. Es liegt also ein Problem damit vor, wie MCEbuddy versucht, die Quelldatei zu löschen bzw. zu überschreiben.
Seitdem ich dies in die profiles.conf eingefügt habe, werden alle Dateien verarbeitet und die Originaldatei durch die bearbeitete ersetzt.
Wer seine Originaldateien archivieren möchte, anstatt sie zu löschen (und es funktioniert nicht mit den integrierten MCEbuddy-Prozessen), kann die CustomCommandParameters entsprechend anpassen. Zum Beispiel kann man die Quelldatei verschieben oder an einen bestimmten Pfad kopieren.
@Goose Hast du eine Ahnung, welche Prozesse in der MCEbuddy-Verarbeitungskette mit höheren Rechten ausgestattet werden könnten (Rechtsklick > Kompatibilität > Programm als Administrator ausführen), um eine erzwungene Löschung von Dateien zu ermöglichen?
Es handelt sich wahrscheinlich um einen Race-Condition-Fall: Etwas greift gerade auf Ihre Datei zu, während MCEBuddy sie löschen will, weshalb der Vorgang fehlschlägt. Darum kann MCEBuddy Ihre Datei nicht vom temporären Ordner in den Quellordner verschieben und bricht mit der Meldung „Datei existiert bereits“ ab.
Ich habe gesehen, dass Ihr Zieldateiname mit dem Originalnamen übereinstimmt (Filename.ts), weshalb das Verschieben scheitert, wenn das Löschen fehlschlägt.
Versuchen Sie, den Namen der Zieldatei zu ändern. Wenn es dann klappt, wissen Sie, dass ein anderer Prozess gleichzeitig auf die Datei zugreift, während MCEBuddy die Originaldatei löschen will.
Ja, ich weiß. Aber ich habe den gesamten Vorgang die ganze Zeit über ein Tool beobachtet, das überprüft, welcher Prozess die Quelldatei genau in dem Moment aufruft, in dem MCEBuddy versucht, die Quelle zu löschen und die neue Datei ins Ziel zu kopieren. Es ist der mcebuddyservice, ausschließlich dieser Prozess, jedes einzelne Mal. Wenn vor diesem Kopiervorgang die benutzerdefinierten Befehle ausgeführt werden, tritt diese Sperre nicht auf. Der Dateiname muss mit dem Original identisch sein, damit mein Receiver die Datei als von ihm selbst aufgenommen erkennt. Verstehst du?