Anfängerfrage: WAS hab ich hier gemacht? ;-)

[GunWi]

Hallo,

sorry, eine absolute Anfängerfrage oder eher noch Anfängerfehler:
Was habe ich hier gemacht, mal abgesehen davon, dass ich nach dem "cd ordner1" die Entertaste nicht deutlich genug gedückt habe :confused:

user@TEST:~/test_117# cd ordner1 mv * ../ordner2/

Ordnerstruktur ist:
test_117
test_117/ordner1 (hier wollte ich NACH cd mit mv alle Dateien nach
test_117/ordner2 moven, aber dass Enter nach dem cd ordner1 verschlampt)

Futsch isset ;-) Vielen Dank für Tipps....

GunWI

[DrunkenFreak]

Vermutlich ist nichts passiert, außer dass du jetzt in ~/test_117/ordner1 stehst. Es könnte aber auch eine Fehlermeldung gekommen sein und nichts passiert sein.

[corresponder]

user@TEST:~/test_117# mv ordner1 ordner2

so lacht es

;-)

[GunWi]

Zunächst Danke für die flotten Antworten!



Vermutlich ist nichts passiert, außer dass du jetzt in ~/test_117/ordner1 stehst. Es könnte aber auch eine Fehlermeldung gekommen sein und nichts passiert sein.

Fast.

Ja, ich bin danach im ~/test_117/ordner1
jedoch sind die Dateien, welche vorher darin befindlich waren, weg.

Nein, sie sind weder im
~/test_117/ordner2
noch befindet sich der der ordner1 im
~/test_117/ordner2

Kopfkratz ;-)

GunWi

[Newbie314]

Probiere mal ein "find -name" (Details "man find") nach einem der Namen der Dateien die du bewegen wolltest.

[BetterWorld]

Um die Frage wirklich beantworten zu können, solltest du erst einmal kundtun, welche Shell du verwendest.
Das ist von Shell zu Shell und System zu System unterschiedlich.

Außerdem wäre ein env gut zu wissen, da viele Shells, die cd als internes Kommando bereitstellen, auch bestimmte Variablen beachten.

Und ich glaube nicht, dass die Dateien weg sind.
Da hättest du noch anderes dazu gepfuscht.

[GunWi]

Probiere mal ein "find -name" (Details "man find") nach einem der Namen der Dateien die du bewegen wolltest.

Hallo,

dies habe ich bereits gemacht - kein Treffer.

Ich habe dies ganze nun nochmal nachgebaut - der eigentliche Fehler war vorher!
Im ordner1 befand sich vorher die Datei testdatei1.zip:
(mit set -x )

user@420:~/test_118/ordner1# ls ../ordner2
+ ls --color=auto ../ordner2
ordner2 ist leer

user@420:~/test_118/ordner1# mv * ../ordner2/
+ mv '*' ../ordner2/
mv: Aufruf von stat für „*“ nicht möglich: Datei oder Verzeichnis nicht gefunden
und hier ist der Fehler, aber wo habe ich testdatei1.zip nun hingemoved?

Nachher sind beide Ordner leer, ein cd / mit anschliessendem find -name testdatei1* bringt keinen Treffer.

Ich gehe mal davon aus, dass ich einfach gerade mitten im Wald stehe....und zwar so was von ;-)
Bin mal gespannt, wie lange ich bis zum Facepalm brauche :D

SHELL=/bin/bash
TERM=xterm
SMP Debian 3.18.6-1 x86_64 GNU/Linux


GunWi

[BetterWorld]

*soifz* Der Output von env fehlt. Wie ich schrieb, haben EINIGE variablen Einfluss auf das, was da wirklich passiert. z.B. CDPATH. Es gibt aber noch mehr, die da mitspielen.

[GunWi]

*soifz* Der Output von env fehlt. Wie ich schrieb, haben EINIGE variablen Einfluss auf das, was da wirklich passiert. z.B. CDPATH. Es gibt aber noch mehr, die da mitspielen.

Okay, hier komplett:
env
SSH_AGENT_PID=3554
GPG_AGENT_INFO=/user/.cache/keyring-Q9q7eD/gpg:0:1
SHELL=/bin/bash
TERM=xterm
XDG_SESSION_COOKIE=90b890bf443f4abc889c37d7549e70c c-1439736716.534555-487606127
WINDOWID=62915908
GNOME_KEYRING_CONTROL=/user/.cache/keyring-Q9q7eD
USER=user
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so =01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;0 1:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st= 37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31 :*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31: *.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=0 1;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31: *.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.d eb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear =01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=0 1;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;3 5:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35 :*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:* .xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*. svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.m ov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mk v=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v =01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=0 1;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01; 35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35 :*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.y uv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx =01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00 ;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00 ;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36 :*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:* .xspf=00;36:
SSH_AUTH_SOCK=/user/.cache/keyring-Q9q7eD/ssh
USERNAME=user
SESSION_MANAGER=local/420:@/tmp/.ICE-unix/3464,unix/420:/tmp/.ICE-unix/3464
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DESKTOP_SESSION=default
PWD=/user/test_117/drift
GNOME_KEYRING_PID=3446
LANG=de_DE.UTF-8
GDM_LANG=de_DE.UTF-8
GDMSESSION=default
SHLVL=1
HOME=/user
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LOGNAME=user
XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-b49mDlkDIX,guid=da69ff6ab00f186babf81da155d0a38d
WINDOWPATH=7
DISPLAY=:0.0
XAUTHORITY=/var/run/gdm3/auth-for-root-s11kpw/database
COLORTERM=gnome-terminal
_=/usr/bin/env
OLDPWD=/user/test_117

GunWi

[BetterWorld]

Da keine Var gesetzt ist, die cd beeinflussen, ist genau nichts passiert.

Der interne cd der bash ignoriert das zweite Argument. (Falls keine Options angegeben werden.)
Siehe help cd
Der mv Befehl wird also nicht ausgeführt. Auch die Globexpansion des Sterns führt nur zu weiteren ignorierten Argumenten.

Gucke, ob du evtl. in GENAU dieser Shell einen Alias für cd hast. Das wäre noch die letzte Möglichkeit.

Was sonst aufällt, ist, dass dein User user wohl im Verzeichnis /user sein home zu haben scheint.
Das ist ungewöhnlich.
Was ergibt ein getent passwd user ?

[GunWi]

Hallo BetterWorld,

getent passwd user ergibt keinerlei Ausgabe, getent passwd (also ohne user) schon.
Ich habe nun mal ein anderes System verwendet - und dort tritt der "Fehler" nicht auf.
Es ist vom Grundsatz her dass gleiche System, dort sieht es so aus:

root@test:~/testmv# ls -la
insgesamt 16
drwxr-xr-x 4 root root 4096 Aug 17 20:10 .
drwxr-xr-x 71 root root 4096 Aug 17 20:09 ..
drwxr-xr-x 2 root root 4096 Aug 17 20:12 ordner1
drwxr-xr-x 2 root root 4096 Aug 17 20:10 ordner2
root@test:~/testmv# ls -la ./ordner1
insgesamt 12
drwxr-xr-x 2 root root 4096 Aug 17 20:12 .
drwxr-xr-x 4 root root 4096 Aug 17 20:10 ..
-rw-r--r-- 1 root root 3 Aug 17 20:11 Dokument
root@test:~/testmv# cd ordner1 mv * ../ordner2/
root@test:~/testmv/ordner1# ls
Dokument
root@test:~/testmv/ordner1# mv * ../ordner2/
root@test:~/testmv/ordner1# ls -la
insgesamt 8
drwxr-xr-x 2 root root 4096 Aug 17 20:22 .
drwxr-xr-x 4 root root 4096 Aug 17 20:10 ..
root@test:~/testmv/ordner1# ls -la ../ordner2/
insgesamt 12
drwxr-xr-x 2 root root 4096 Aug 17 20:22 .
drwxr-xr-x 4 root root 4096 Aug 17 20:10 ..
-rw-r--r-- 1 root root 3 Aug 17 20:11 Dokument
root@test:~/testmv/ordner1#

Ich gehe konform mit Dir, dass mein "cd ordner1 mv * ../ordner2/" NUR das cd zu ordner1 zur Folge haben dürfte.
Dies ist auf beiden Rechnern auch so.

Bleibt für mich die Frage, warum auf dem Problemrechner dass mv * ../ordner2/ zu einem Fehler UND zum verschwinden der Datein führt -
auf dem zweiten Rechner jedoch der Befehl einwandfrei funktioniert. Insbesondere habe ich den Befehl auf dem Problemrechner bereits
mehrfach ohne Probleme verwendet - in der gleichen Sitzung, über die history (cursor up). Bis auf den falschen "cd ordner1 mv * ../ordner2/"
Ein Alias für cd existiert nicht.
Den kompletten Puffer der Sitzung habe ich mir auch gesichert - also auch die Aufrufe von mv * ../ordner2/ welche vorher funktioniert haben.
Dazu wäre noch zu sagen, dass in ordner1 vorher ca. 5000 Dateien waren....

Auch wenn es micht nicht befriedigt, werde ich den Problemrechner mal neu starten und schauen, ob es dann wieder geht.
Meiner Meinung nach dürfte dies nicht so passieren, oder ist vom Grundsatz her etwas an
mv * ../ordner2/
falsch? Sicher könnte ich auch schreiben:
mv * /user/test_118/ordner2

Danke erstmal für die Tipps - werde berichten ob und was ich herausfinde, Ausgaben von
env
getent passwd
werde ich sichern - vor und nach dem boot.

Sonst noch etwas? Werde selber auch der Sitzung noch soviel als mir als Anfänger möglich an Informationen entlocken.

GunWi

[BetterWorld]

Der mv Befehl mit relativem Pfad ist völlig in Ordnung.
Alles kein Problem.

Und der erste "mißglückte" Befehl hat in der bash garantiert nichts getan. Er wechselte das cwd und ignorierte den Rest der gegebenen Parameter.

Also wirklich alles in Ordnung.

Ich dachte auf Grund deines Envrionments:
USER=user
OLDPWD=/user/test_117
halt, dass du einen User namens user hast und dessen home im / liegt.
Das hat der getent passwd user widerlegt.
Es erschien mir halt sehr komisch und es war auch klar, dass es mit dem Befehl nichts zu hat.

Als dir das passiert ist, ist irgendetwas anderes schief gegangen. Was auch immer.
Du hast wirklich den ganzen Verzeichnisbaum nach Dateinamen aus dem Verzeichniss ordner1 durchsuchen lassen?
Mit welchem Befehl __genau__ ?

[GunWi]

Hallo,

mit find -name dateiname*
aus / heraus.

Meine Vermutung (mit weiteren Infos)
In Ordner1 kommen laufend Dateien aus einem anderen Terminal, Namenskonvention ist halt
dateiname-Eindeutiger_ZUFALLSWERT.ext

Zum Zeitpunkt x gehe ich her, verschiebe eben diese Dateien aus ordner1 mittels mv * ../ordner2/ ,
komprimiere diesen ordner2 (als zip) via Kontextmenue in der Ordneranzeige (Orte->Persönlicher Ordner/usw....)
lösche mit rm ../ordner2/* dort dann alle Dateien
(während im Hintergrund in ordner1 laufend weitere Dateien an/abgelegt werden)
Ja, ich weiss, dass ich mit zB gzip dies auch direkt im ordner1 hätte erledigen können, habe diesen Weg aber nunmal so gewählt ;-)

Nun kommt es aber Dicke:
Wie gesagt kann es durchaus sein, dass in ordner1 (und logischerweise auch dann ordner2) mehrere tausend Dateien sind, welche komprimiert durchaus
2GB ergeben kann.
Dass erste find -name fand noch etliche Dateien ind der Form:
dateiname-5596949752c90bb1.ext.trashinfo in ~/.local/share/Trash/info/
allerdings nur mit Inhalt Dateiname-LöschdatumZeit - also unnütz für mich - zudem nicht die aktuellen Dateien sondern teilweise 1 Tag alt....
Die Originaldateien sind weg...
jedoch funktioniert nun sowohl im extra angelegtem Testordner als auch im Produktivordner
meine bisherige Vorgehensweise, ohne dass ich etwas geändert hätte.

Kann es sein, dass Linux noch mit etlichen Dateioperationen "überfordert" war?
Die HDD hat noch genug Platz (sonst hätte der Prduktive Part ja auch nicht mehr funktioniert)
jedoch wie gesagt ist die eine (!) Datei im Testordner ja auch verschwunden - und gerade eben beim Test ohne weiteres zutun wieder alles gut - Datei wurde wie erwartet verschoben, ebenso im Produktivbereich bereits wieder 1900 Dateien....

Dateisystem ist ext4. mit 8GB Swap-Bereich in eigener Partition.

Hätte nicht passieren dürfen, zumindest nicht der Datenverlust (welcher nun nicht dramatisch ist)....ist es aber.
Ich hätte im Nachhinein mit einer Fehlermeldung und/oder verzörgertem Dateihandling gerechnet - aber nicht damit.

Danke nochmals für die Hilfe, werde in Zukunft dieses Verhalten mit doppeltem Netz ;-) nochmal austesten und dem System mehr Zeit geben.
(Windows hätte ich so etwas immer zugetraut - Linux nicht, grins....)


GunWi