Der Befehl mv meldet "X und Y sind die gleiche Datei", cifs-Dateisystem
1778
cgram
Ich versuche, ein Skript zu erhalten, mit dem Videos umbenannt und verschoben werden. Folgendes habe ich:
#!/bin/bash src="/mnt/Files_Apps/temp/" dest="/mnt/Files_Apps/TFTP root/" for file in "$src"*.*; do newfile="$$(date -r "$file" +"%Y-%m-%d %H %M %S").MOV" mv "$file" "$newfile" done
Ich habe den Inhalt des Quellverzeichnisses mehrmals geändert. Einige Dateien werden verschluckt, andere funktionieren einwandfrei. Ich kann nicht herausfinden, warum bestimmte Dateien (alle im .MOV-Format, importiert von meinem iPhone) als Duplikate angezeigt werden.
Ausgabe von mount:
//GRAMNAS/Files_Apps on /mnt/Files_Apps type cifs (rw,relatime,vers=1.0,sec=ntlm,cache=strict,username=xxxxx,uid=1208001104,forceuid,gid=1208001114,forcegid,addr=x.x.x.x,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=1048576,actimeo=1)
ls -li auf src vor der Skriptausführung:
~/.scripts$ ls -li /mnt/Files_Apps/temp/ total 697384 13238340 -rwxrwxrwx 1 chris linuxadmin 8844047 Jul 19 21:39 IMG_5624.MOV 13238349 -rwxrwxrwx 1 chris linuxadmin 96701684 Apr 14 11:58 IMG_7355.MOV 13238366 -rwxrwxrwx 1 chris linuxadmin 98690685 Apr 17 15:06 IMG_7426.MOV 13238384 -rwxrwxrwx 1 chris linuxadmin 100289499 May 5 14:32 IMG_7568.MOV 13238579 -rwxrwxrwx 1 chris linuxadmin 75031725 May 8 11:57 IMG_7662.MOV 13239032 -rwxrwxrwx 1 chris linuxadmin 86233885 May 9 10:13 IMG_7672.MOV 13239098 -rwxrwxrwx 1 chris linuxadmin 76930641 May 9 16:03 IMG_7687.MOV 13239466 -rwxrwxrwx 1 chris linuxadmin 78796811 May 13 13:22 IMG_7806.MOV 13240809 -rwxrwxrwx 1 chris linuxadmin 92599209 May 14 12:39 IMG_7951.MOV
ls -li on dest vor der Skriptausführung:
~/.scripts$ ls -li /mnt/Files_Apps/TFTP\ root/ total 0
Skriptausgabe:
~/.scripts$ bash -v videorename.sh date -r "$file" +"%Y-%m-%d %H %M %S" mv: '/mnt/Files_Apps/temp/IMG_5624.MOV' and '/mnt/Files_Apps/TFTP root/2016-07-19 21 39 21.MOV' are the same file date -r "$file" +"%Y-%m-%d %H %M %S" mv: '/mnt/Files_Apps/temp/IMG_7355.MOV' and '/mnt/Files_Apps/TFTP root/2016-04-14 11 58 26.MOV' are the same file date -r "$file" +"%Y-%m-%d %H %M %S" mv: '/mnt/Files_Apps/temp/IMG_7426.MOV' and '/mnt/Files_Apps/TFTP root/2016-04-17 15 06 35.MOV' are the same file date -r "$file" +"%Y-%m-%d %H %M %S" . . .
ls -li auf src nach Skriptausführung:
~/.scripts$ ls -li /mnt/Files_Apps/temp/ total 697384 13238340 -rwxrwxrwx 1 chris linuxadmin 8844047 Jul 19 21:39 IMG_5624.MOV 13238349 -rwxrwxrwx 1 chris linuxadmin 96701684 Apr 14 11:58 IMG_7355.MOV 13238366 -rwxrwxrwx 1 chris linuxadmin 98690685 Apr 17 15:06 IMG_7426.MOV 13238384 -rwxrwxrwx 1 chris linuxadmin 100289499 May 5 14:32 IMG_7568.MOV 13238579 -rwxrwxrwx 1 chris linuxadmin 75031725 May 8 11:57 IMG_7662.MOV 13239032 -rwxrwxrwx 1 chris linuxadmin 86233885 May 9 10:13 IMG_7672.MOV 13239098 -rwxrwxrwx 1 chris linuxadmin 76930641 May 9 16:03 IMG_7687.MOV 13239466 -rwxrwxrwx 1 chris linuxadmin 78796811 May 13 13:22 IMG_7806.MOV 13240809 -rwxrwxrwx 1 chris linuxadmin 92599209 May 14 12:39 IMG_7951.MOV
ls -li auf dest nach Skriptlauf:
~/.scripts$ ls -li /mnt/Files_Apps/TFTP\ root/ total 0
Das ist irrational. Verwenden Sie RedHat oder eine verwandte Distribution? In diesem Bereich scheint es Probleme zu geben, wie [this] (https://access.redhat.com/solutions/1284993), ohne dass es eine aktuelle Lösung gibt. Ich bin selbst auf Ubuntu und habe diese Nachricht trotz häufiger Verwendung von "mv" noch nie gesehen. Ich kann nicht einfach testen, ob Sie kein von Debian abgeleitetes System verwenden. Sie könnten versuchen, zu einem anderen Dateisystem zu wechseln und zurück: Ich habe instinktiv das Gefühl, dass dies eine Work-Round ist, aber ich kann nicht testen, und Sie werden es erst wissen, wenn Sie es versuchen.
AFH vor 7 Jahren
0
Ich bin auf dem neuesten Ubuntu
cgram vor 7 Jahren
0
Ich bin auf Ubuntu 16.04.1 und habe so etwas noch nie gesehen. Die einzig mögliche Erklärung, die mir einfällt, ist, dass es zwischen den Dateien oder Verzeichnispositionen Links (symbolisch oder hart) gibt.
AFH vor 7 Jahren
0
@cgram: (1) Ich habe Ihre Frage bearbeitet. Ich habe `` in `$ ` geändert, da Sie die von Ihnen gemeldeten Ergebnisse ohne das `$` nicht hätten bekommen können. (PS Sie könnten stattdessen "$ dest" verwenden. Sie benötigen selten die geschweiften Klammern; siehe [this] (http://unix.stackexchange.com/q/32210/23408#286525).) Sie haben keine anderen Tippfehler in Ihrer Frage. (2) Können Sie vor und nach dem Ausführen Ihres Skripts `ls -li` für die Quell- und Zielverzeichnisse tun und die Ausgabe posten? Bitte antworten Sie nicht in Kommentaren. Bearbeiten Sie Ihre Frage, um sie klarer und vollständiger zu machen.
Scott vor 7 Jahren
0
@Scott ... Danke für die Korrektur, aber ich hatte das $ in meinem eigentlichen Skript ... die Frage war nur ein Tippfehler ... entschuldigt. Ich habe eine weitere Testrunde durchgeführt und die Frage zusammen mit ls -li vor / nach dem Skriptlauf mit den Ergebnissen aktualisiert. Interessant ist, wenn ich die Leerzeichen aus dem Newfile nehme: "newfile =" $ (Datum -r "$ file" + "% Y-% m-% d-% H-% M-% S"). MOV "", es funktioniert gut.
cgram vor 7 Jahren
0
2 Antworten auf die Frage
1
cgram
Wie sich herausstellte, drehte sich das Problem darum, wie die CIFS-Freigabe gemountet wurde. Es scheint, dass der Inode möglicherweise zwischengespeichert wurde. Dadurch werden die meisten Dateien dupliziert, wenn das Skript versucht, den neuen Dateinamen zu schreiben. Um dies zu beheben, fügte ich 'cache = none' hinzu und fountete die Freigabe erneut. Ich habe das Skript seitdem mehrmals ohne Probleme durchlaufen.
Obwohl ich weiß, WAS das Problem war, bin ich immer noch nicht ganz sicher, WARUM es in Frage kam. Wenn jemand weiß, wie sich dies auf die CIFS-Montierung auswirkt, bin ich ganz Ohr.
0
yarl
Räume sind nicht so langwierig zu handhaben:
#!/bin/bash src="/mnt/Files_Apps/temp/" dest="/mnt/Files_Apps/TFTP root/" for file in "$src"*.*; do newfile="$$(date -r "$file" +"%Y-%m-%d %H %M %S").MOV" mv "$file" "$newfile" done
Sag mir, wenn es dein Problem löst. Zumindest ist es einfacher.
Das ist sauberer, danke. Ich erhalte jedoch immer noch die gleiche Fehlermeldung: mv: '/mnt/Files_Apps/temp/IMG_8431.mov' und '/ mnt / Files_Apps / TFTP root / 2016-05-25 18 08 23.MOV' sind die gleichen Dateien
cgram vor 7 Jahren
0
Haben Sie versucht, die MV manuell zu machen? Wenn das nicht funktioniert, versuchen Sie, die Zieldatei leer zu erstellen.
yarl vor 7 Jahren
0
Ich habe es gerade gemacht ... und es funktioniert. Es muss so sein, wie die Schleife mit Leerzeichen umgeht, ich kann einfach nicht herausfinden, was das Problem ist.
cgram vor 7 Jahren
0
Sie haben meinen Code kopiert, oder?
yarl vor 7 Jahren
0
Ich habe Ihren Code kopiert / eingefügt. Seltsam ist, dass ich diesen Fehler nur für eine Datei bekomme. Wenn ich das Zielverzeichnis bereinige und das Skript nur für diese eine Datei ausführte, erhalte ich immer noch den Fehler. Und für das, was es wert ist ... dasselbe passiert, wenn ich 'mv' in 'cp' ändere.
cgram vor 7 Jahren
0
Können Sie Ihre Frage mit neuen Informationen bearbeiten? neuer Code, neue Tests. Fügen Sie auch das Dateisystem hinzu, das Sie verwenden (lsblk -f).
yarl vor 7 Jahren
0
yarl ... Ich habe die ursprüngliche Frage mit dem aktuellen Code und einer aktuellen Ausgabe aktualisiert. Ich bin verblüfft
cgram vor 7 Jahren
0
Ein weiterer Vorbehalt .... Wenn ich die Box neu starte und das Skript erneut ausführte (ohne etwas in den Quell- oder Zielverzeichnissen zu ändern), funktioniert es plötzlich. Könnte es etwas im Cache geben, das dies verursacht?
cgram vor 7 Jahren
0
Kannst du deinen Beitrag mit dem relevanten Teil der Ausgabe von "mount" bearbeiten?
yarl vor 7 Jahren
0
Ich gehe davon aus, dass Sie das meinten.
cgram vor 7 Jahren
0
ein weiteres Stück Info .... wenn ich die Leerzeichen in der neuen Datei entferne "newfile =" $ (Datum -r "$ file" + "% Y-% m-% d-% H-% M-% S) ") .MOV" ", es funktioniert gut.
cgram vor 7 Jahren
0
Ja, das habe ich gemeint. Ich kenne Cifs nicht genug. Ich kann nicht mehr versuchen zu helfen.
yarl vor 7 Jahren
0