Mv und vfat

Moin

Ich mounte eine 25 GB-FAT32-Platte unter debian (testing, 2.4.21). Auf der Platte sind folgende Dateien:

temp (Verzeichniss)
 |
 \-- file1
 \-- file2
Data

Bin per cd in Data, und habe mich dort vertippt (es fehlt der „.“ als Zielangabe:

mv ../temp/file\*

Erstaunlicherweise kam keine Fehlermeldung und die Datei „file1“ war weg (Auch unter windows). Das ist reproduziertbar auf allen gemounteten FAT32-Partitionen, geht aber nicht auf EXT2/3. (Ich hab nur ein System zu testen und knoppix nicht zur Hand)

Soll das so ?

Meinem Verständniss von mv nach müsste mv einfach die Ausführung verweigern, da ein Parameter fehlt. Andererseites gehts auf EXT2/3 nicht, also müsste es an vfat liegen. Wieso bekommt vfat was von einem falsch eingetippen mv-Befehl mit ?

cu

Moin

Moin,

Auf der Platte sind folgende Dateien:

temp (Verzeichniss)
|
– file1
– file2
Data

Bin per cd in Data, und habe mich dort vertippt (es fehlt der
„.“ als Zielangabe:

mv …/temp/file*

Erstaunlicherweise kam keine Fehlermeldung und die Datei
„file1“ war weg (Auch unter windows).

So erstaunlich ist das nicht.

Das ist reproduziertbar
auf allen gemounteten FAT32-Partitionen, geht aber nicht auf
EXT2/3. (Ich hab nur ein System zu testen und knoppix nicht
zur Hand)

Soll das so ?

Ja.

Meinem Verständniss von mv nach müsste mv einfach die
Ausführung verweigern, da ein Parameter fehlt. Andererseites
gehts auf EXT2/3 nicht,

Das wuerde mich sehr wundern (und waere wirklich ein Fehler)!

also müsste es an vfat liegen. Wieso
bekommt vfat was von einem falsch eingetippen mv-Befehl mit ?

Verstaendnis fehlt Dir vielleicht noch ein wenig. Die Dateinamen-Expansion uebernimmt die Shell , nicht das Programm, wie bei MS-DOS. Wenn Du (egal wo) file* hinschreibst ersetzt die Shell dies durch alle matches (in dem Fall also file1 und file2). Ausnahme waere, wenn es keinen Match gibt, dann kriegt mv wirklich file* zu sehen (und wird damit wahrscheinlich nichts anfangen koennen). Der mv sah also so aus:

mv ../temp/file1 ../temp/file2

. file1 wurde ueber file2 verschoben. Voellig korrekt, aber eine Stolperfalle. Naeheres findet sich betimmt in 'man basename $SHELL'.

cu

HTH
Gruss vom Zentrum.

Das wuerde mich sehr wundern (und waere wirklich
ein Fehler)!

Sorry, aber das wundert mich nicht. Der Befehl

mv ../temp/file\*

erzeugt nichts anders als die Fehlermeldung

mv: when moving multiple files, last argument must be a directory

Alles andere würde mich wundern.

Der mv sah
also so aus:

mv …/temp/file1 …/temp/file2

. file1
wurde ueber file2 verschoben.

Das hört sich ja überaus plausibel an, aber der mv sah erst mal so aus:

mv ../temp/file\*

mv überprüft zunächst die Anzahl der Parameter, stellt fest, dass einer fehlt, und bricht mit einer Fehlermeldung ab. Es kommt also erst gar nicht zur shell-Expansion.

Da ich aus religösen Gründen kein vfat32 benutzen darf, kann ich leider nicht nachvollziehen, was es da mit der moverei auf sich hat. Auf ext3 jedenfalls verhält sich der mv so, wie ich das von ihm erwarte.

Für mich hört sich die Geschichte sehr befremdlich an. Ich habe keine Erklärung dafür, warum mv sich auf einer vfat32-Partition anders verhalten sollte als auf einer ext3-Partition.

Stefan

(Ich bitte zu beruecksichtigen, dass ich mich komplett auf die Bourn-Shell beziehe.)

Das wuerde mich sehr wundern (und waere wirklich
ein Fehler)!

Sorry, aber das wundert mich nicht. Der Befehl ‚mv
…/temp/file*‘ erzeugt nichts anders als die
Fehlermeldung ‚mv: when moving multiple files, last
argument must be a directory‘ Alles andere würde mich
wundern.

Das ist, sorry, kompletter Quatsch. Diese Fehlermeldung entsteht, wenn es mehr als zwei Matches gibt. Dann expandiert die Shell die Zeile naemlich zu (z. B.)

mv file1 file2 file3

. file3 ist kein Verzeichnis -> Fehler.

Der mv sah
also so aus: ‚mv …/temp/file1 …/temp/file2‘. file1
wurde ueber file2 verschoben.

Das hört sich ja überaus plausibel an, aber der mv sah erst
mal so aus: ‚mv …/temp/file*‘ mv überprüft zunächst
die Anzahl der Parameter, stellt fest, dass einer fehlt, und
bricht mit einer Fehlermeldung ab. Es kommt also erst gar
nicht zur shell-Expansion.

Nein. Erst shell expansion, dann wir der Befehl aufgerufen. glaubst Du ein

echo \*

sucht sich selbst alle Dateien zusammen? Das hat nicht einen Schimmer vom filesystem. Das macht vorher die shell und die fuehrt dann

echo foo bar foobar

aus. Du darfst es gern probieren (Vorsicht, untested!):

#include 

int main(int argc, char\*\* argv)
{
 int i;
 for(i=0; i
Dieses Programm kuemmert sich einen feuchten um Dateien oder Verzeichnisse. Dennoch wirst Du mit 

    a.out \*

 ein komplettes Verzeichnislisting kriegen.



> Da ich aus religösen Gründen kein vfat32 benutzen darf, kann  
> ich leider nicht nachvollziehen, was es da mit der moverei auf  
> sich hat. Auf ext3 jedenfalls verhält sich der mv so, wie ich  
> das von ihm erwarte.  
>   
> Für mich hört sich die Geschichte sehr befremdlich an. Ich  
> habe keine Erklärung dafür, warum mv sich auf einer  
> vfat32-Partition anders verhalten sollte als auf einer  
> ext3-Partition.


Tut es nicht, weil es vom filesystem gar nichts sieht, das macht der Kernel. Du hast nicht die richtige Umgebung geschaffen, um das (voellig korrekte) Verhalten zu reproduzieren.



> Stefan


HTH,
 Gruss vom Zentrum.

Sorry, aber das wundert mich nicht. Der Befehl

mv
…/temp/file*

erzeugt nichts anders als die
Fehlermeldung

mv: when moving multiple files, last
argument must be a directory

Alles andere würde mich
wundern.

Wenn es 2 Files sind nicht. „multiple files“ gilt erst ab 3 Parametern.

Das hört sich ja überaus plausibel an, aber der mv sah erst
mal so aus:

mv …/temp/file*

mv überprüft zunächst
die Anzahl der Parameter, stellt fest, dass einer fehlt, und
bricht mit einer Fehlermeldung ab. Es kommt also erst gar
nicht zur shell-Expansion.

Nein, die shell-expansion kommt bevor der mv befehl gestartet wird. mv bekommt wirklich 2 Parameter, naemlich die 2 Files.

Für mich hört sich die Geschichte sehr befremdlich an. Ich
habe keine Erklärung dafür, warum mv sich auf einer
vfat32-Partition anders verhalten sollte als auf einer
ext3-Partition.

Das geht mir genauso. Bei mir ist kein Unterschied zwischen Ext3 und vfat festzustellen.

Gruss
Timo

Das ist, sorry, kompletter Quatsch. Diese Fehlermeldung
entsteht, wenn es mehr als zwei Matches gibt. Dann expandiert
die Shell die Zeile naemlich zu (z. B.)

mv file1 file2
file3

. file3 ist kein Verzeichnis -> Fehler.

Also, ich hab das tatsächlich erst einmal ausprobiert, bevor ich gepostet habe. Die Fehlermeldung wird ausgeworfen, wenn ich mit der diskutierten Konfiguration (zwei files ‚file1‘ und ‚file2‘) den Befehl ‚mv …/temp/file*‘ eingebe. So wie es pumpkin beschreibt.

Nein. Erst shell expansion, dann wir der Befehl
aufgerufen.

Ich verstehe. Nach einigem Meditieren ist es völlig logisch. Sogar für mich :wink:

Tut es nicht, weil es vom filesystem gar nichts sieht, das
macht der Kernel. Du hast nicht die richtige Umgebung
geschaffen, um das (voellig korrekte) Verhalten zu
reproduzieren.

Wie soll ich das verstehen? Ich habe bislang lediglich die Umgebung geschaffen, die pumpkin in seinem Urprungspost beschrieben hat (auch wenn das letztendlich überhaupt keine Rolle spielen sollte), und ich bekomme die angesprochene (und IMHO korrekte) Fehlermeldung. Und alle Dateien sind immer noch da, wo sie sein sollen.

Auf meiner Sun unter Solaris 2.7 passiert genau das, was du beschreibst - eine Datei wird überschrieben. Auf dem Linuxkasten (übrigends ext2) kommt die besagte Fehlermeldung. Interessant.

Stefan

Das ist, sorry, kompletter Quatsch. Diese Fehlermeldung
entsteht, wenn es mehr als zwei Matches gibt. Dann expandiert
die Shell die Zeile naemlich zu (z. B.)

mv file1 file2
file3

. file3 ist kein Verzeichnis -> Fehler.

Also, ich hab das tatsächlich erst einmal ausprobiert, bevor
ich gepostet habe. Die Fehlermeldung wird ausgeworfen, wenn
ich mit der diskutierten Konfiguration (zwei files ‚file1‘ und
‚file2‘) den Befehl ‚mv …/temp/file*‘ eingebe. So wie es
pumpkin beschreibt.

Nein, ich glaub Dir’s nicht. Wenn das wirklich so ist komm ich persoenlich nach FraFu und guck mir dieses eigentuemliche Dateisystem an.

Nein. Erst shell expansion, dann wir der Befehl
aufgerufen.

Ich verstehe. Nach einigem Meditieren ist es völlig logisch.
Sogar für mich :wink:

Gut.

Du hast nicht die richtige Umgebung
geschaffen, um das (voellig korrekte) Verhalten zu
reproduzieren.

Wie soll ich das verstehen? Ich habe bislang lediglich die
Umgebung geschaffen, die pumpkin in seinem Urprungspost
beschrieben hat (auch wenn das letztendlich überhaupt keine
Rolle spielen sollte), und ich bekomme die angesprochene (und
IMHO korrekte) Fehlermeldung. Und alle Dateien sind immer noch
da, wo sie sein sollen.

Ja wie denn, ich dachte, Du glaubst es endlich?

Auf meiner Sun unter Solaris 2.7 passiert genau das, was du
beschreibst - eine Datei wird überschrieben. Auf dem
Linuxkasten (übrigends ext2) kommt die besagte Fehlermeldung.
Interessant.

Das waere in der Tat interessant. Weil Du einen Bug gefunden haettest, den (bei allem Respekt) mindestens 10,000 Leute vor Dir entdeckt haetten. Was sagt im verdaechtigen Verzeichnis

echo $SHELL
echo ../temp/file\*
mkdir $USER.$$
cd $USER.$$
touch file1 file2
mv file\*
ls

?

Stefan

Neugierigen
Gruss vom Zentrum.

Das waere in der Tat interessant. Weil Du einen Bug gefunden
haettest, den (bei allem Respekt) mindestens 10,000 Leute vor
Dir entdeckt haetten.

Ich hab übrigens herausgefunden, warum sich meine Maschine so anders verhält. Ziemlich simpel: es liegt einwandfrei daran, dass ich ein Depp bin (wenn man einer ist, dann muss man es auch zugeben). Du brauchst also nicht extra erst nach Frankfurt zu kommen, um mir die Ohren lang zu ziehen :smile:

Ich war fest der Meinung, dass ich /tmp/temp völlig neu angelegt hatte. Dem war aber nicht so. Das gabs offenbar schon, und um dem Ganzen die Krone aufzusetzen, war es zufälligerweise gefüllt mit köstlichen Dateien, deren ersten vier Buchstaben das Wort file ergeben, so wie fileAICd8D oder fileQrOGiT…

Schon schlecht, wenn man glaubt, sein Leben ohne ls verbringen zu können. Ich hab jedenfalls schnell mit touch file1 file2 weitere Dateinamen erzeugt, die mit file beginnen. Mal einen Blick in das Verzeichnis zu werfen habe ich nicht getan.

Aaahrrrgl. Kein Wunder, dass ich eine Fehlermeldung bekam (denn es waren jetzt ja mehr als zwei Dateien im Verzeichnis). Tschulligung, aber dafür muss ich mich jetzt öffentlich als dämlich outen. Das schmerzt genug :wink: Sei so gut und lass es mir als Hitzeschaden durchgehen.

Stefan