Daten kopieren/ Verschiedene Dateiträgerformate

SeppJ

IceArtchi schrieb:

Werden denn die Daten an sich verändert wenn sie von einem Dateisystem auf ein anderes kopiert werden? Ich dachte immer das Dateisystem hätte damit nichts zu tun. Ich selber habe das zumindestens noch nicht gemerkt.

Das wäre eine ziemliche Katastrophe, fändest du nicht?

Ich dachte (und meine Antwort bezog sich da drauf), dass wir hier von Metainformationen reden.

hustbaer

Bei FAT32 => NTFS können sich Timestamps ändern (created, modified, accessed).
Weil FAT32 Lokalzeit und NTFS UTC verwendet.

Und ein fehlerhafter FAT32 und/oder NTFS Treiber könnte natürlich zu Datenverlust führen. Ich gehe aber mal davon aus dass auch der Linux NTFS Treiber mittlerweile ausreichend stabil ist.

Und natürlich kannst du wie SeppJ schon geschrieben hat nen Verify/Diff nach dem Kopieren machen.

Man sollte auch darauf achten, dass das Dateisystem als Fat32 mit Unterstützung langer Dateinamen gemounted wird, denn sonst hat man 8.3 Zeichen lange Dateinamen die dann bei einer Kopie auf NTFS als solche übernommen werden.

Auch kann es sinnvoll sein, die Dateien auf enthaltene Sonderzeichen zu überprüfen.
Es gibt z.b. Leute, die verwenden / als Trennzeichen im Dateiname, weil sie das so vom Internet her kennen.
Bei Windows dürfte das zwar egal sein, aber bei Linux sollte man das tunlichst unterlassen.

Kopiert man in die andere Richtung, von NTFS nach FAT32, dann gehen die ACL Informationen verloren.

SG1

Hinzufüger schrieb:

Bei Windows dürfte das zwar egal sein,

Windows nutzt auch / als Verzeichnisseparator, unterstützt also ziemlich sicher auch kein / in Dateinamen. Ganz allgemein ist Windows deutlich restriktiver, was ein gültiger Dateiname ist, als Linux.

nman

Ergänzung: Die Unterstützung langer Dateinamen muss man nicht extra aktivieren.

hustbaer

SG1 schrieb:

Ganz allgemein ist Windows deutlich restriktiver, was ein gültiger Dateiname ist, als Linux.

???

nman

Naja, Dateinamen unter Windows dürfen vmtl. keine Doppelpunkte oder Pipes enthalten, oder? Backslashes wohl auch nicht. Nicht, dass das je wehtäte, aber ich nehme an, dass SG1 das meinte.

hustbaer

@nman
Ist mir aber lieber als ein OS wo man dauernd Probleme bekommt wenn man Spaces in Dateinamen verwendet

nman

Weiß nicht so recht was du meinst, ich hatte noch nie Schwierigkeiten mit Spaces in Dateinamen. Muss man eben – genauso wie unter Windows auch – escapen oder quoten oder was auch immer.

Aber SG1 hat das ja auch nicht wertend gemeint. Dass Windows diesbezüglich restriktiver ist, ist ja nicht per se gut oder schlecht.

Du meinst wahrscheinlich in der Bash-Autocompletition, da sind Leerzeichen in den Dateinamen wirklich doof. In der Windowsumgebung wird so gut wie alles komplettiert, auch klein- und grossschreibung spielt hier keine Rolle. Ist vielleicht nur Einstellungssache, in den Default-Settings ist das aber so.

hustbaer

Ich meine Globbing.
Die Sternderl-Sache halt.
Versuch mal mit rm * alle Files in einem Verzeichnis zu löschen, wenn da Files mit Spaces im Filenamen drin liegen.
Vielleicht mit nem File namens "-rf . ext" drinnen.

Klar, ist keine Einschränkung auf die Filenamen die Linux bzw. die unter Linux üblichen File-Systeme grundsätzlich erlauben.
Praktisch ist es aber ein Problem, weil unter Linux dummerweise immer noch verdammt viel mit Spucke und Bindfaden (=shell scripts) zusammengebunden ist.

nman

Verstehe ehrlich gesagt überhaupt nicht was du meinst.

~/foo % touch 'Hallo hustbaer'
~/foo % ls
Hallo hustbaer
~/foo % rm *
zsh: sure you want to delete all the files in ~/foo [yn]? y
~/foo % ls
~/foo %

Klar, das war jetzt natürlich zsh, nicht Bash, weil ich kein Bash-User bin. Aber mit bash sieht das nicht auch anders aus.

~/foo$ touch 'Hallo hustbaer'
~/foo$ ls
Hallo hustbaer
~/foo$ rm *
~/foo$ ls
~/foo$

Shellskripte sind da nirgends involviert. Glob ist seit den Siebzigern ein Shell-Builtin.

BashBash: Kann mich nicht erinnern, dass die Standard-Bash-Completion je Schwierigkeiten mit Leerzeichen im Dateinamen gemacht hätte. Schon bei meinen ersten Linux-Gehversuchen in den Neunzigern hat die brav alle Spaces escaped.

nman

Ach ja, noch ein Nachtrag zu der "-rm ."-Geschichte: Ich werde dabei gewarnt, dass das kein gültiger Aufruf ist und es wird nichts gelöscht. Wenn man zum Löschen statt rm * einfach rm ./* verwendet, funktioniert alles genau wie erwartet.

hustbaer

OK.
Dann versuch das ganze mit einem echten Programm. Also etwas was nicht direkt in der Shell eingebaut ist.

Christoph

hustbaer schrieb:

OK.
Dann versuch das ganze mit einem echten Programm. Also etwas was nicht direkt in der Shell eingebaut ist.

Wenn du "./mein_programm *" aufrufst, wird das genau wenig Probleme machen wie "rm *", weil Leerzeichen von der Shell beim globbing korrekt behandelt werden.

Wenn das Programm selber über die Verzeichniseinträge iteriert mit readdir(), wird es auch keine Probleme mit Leerzeichen bekommen.

Einzige Ausnahme (von der ich weiß) sind schlecht geschriebene Shell-Skripte, bei denen das Selber-Iterieren kein Iterieren ist, sondern ein Hack über stdout und word splitting:

for i in `ls *`; do ...; done

statt einfach

for i in ./*; do ...; done

hustbaer

OK.
Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?
Ich hab öfters gehört dass die Shell damit nicht korrekt umgehen kann. Wenn das nicht der Grund ist, was dann?

nman

Cargo Cult? Keine Ahnung.

Ich verwende seit den späten Neunzigern unixoide Betriebssysteme und hatte noch nie Probleme mit Leerzeichen – die von Christoph geschilderten mal ausgenommen.

Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?

Moment, was meinst du denn hiermit eigentlich genau? Wo sollen denn Pfade mit Leerzeichen nicht oder schon verwendet werden? Sorry, ich stehe offensichtlich gerade sehr auf der Leitung.

Christoph

hustbaer schrieb:

Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?

Ein Grund, den ich mir vorstellen kann: In der Shell ist es etwas nervig, mit Leerzeichen im Dateinamen zu arbeiten. Tabvervollständigung funktioniert zwar, aber erzeugt backslash+space oder setzt gleich den ganzen Namen in quotes.

Dasselbe Problem hat man vermutlich bei Dokumentation. Jetzt kann man unmissverständlich /home schreiben. Mit Leerzeichen müsste man das wohl quoten, um es von zwei Pfaden zu unterscheiden. Simples word splitting an spaces macht Englisch und Deutsch leider auch.

audacia

Ein Kollege von mir hat mal einen halben Tag gegen seine Shell gekämpft, weil irgendein Verzeichnis sich einfach nicht löschen lassen wollte. Ursache: trailing space im Verzeichnisnamen.

Mir selbst passiert es öfter, daß irgendwelche GCC-Makefiles nicht gehen, nur weil ich meinen Code in "...\Eigene Dateien\..." liegen habe. Dann muß ich in einem leerzeichenfreien Ordner eine Junction aufs Verzeichnis anlegen, damit es klappt.

Vermutlich tragen derartige Erlebnisse dazu bei, daß Leerzeichen auf Unixoiden insgesamt gemieden werden.

hustbaer

nman schrieb:

Was ist dann der Grund dass bei Linux Programmen kaum bis gar nie Pfade mit Spaces verwendet werden?
Moment, was meinst du denn hiermit eigentlich genau? Wo sollen denn Pfade mit Leerzeichen nicht oder schon verwendet werden? Sorry, ich stehe offensichtlich gerade sehr auf der Leitung.

z.B. Default-Namen für diverse Verzeichnisse (Install Pfade etc.).
Auf Windows hast du z.B. schonmal vom System aus Pfade wie
`c:\Program Files

c:\Program Files (x86)

c:\Windows\Downloaded Installations

c:\Windows\Offline Web Pages

etc.`

Und bei ThirdParty Programmen gibt's auch sehr häufig Pfade mit Leerzeichen. Natürlich gibt's auch hier Ausnahme, das dumme DDK mag z.B. keine Leerzeichen im Pfad (ist mittlerweile möglicherweise gefixt, das Win2000 DDK mochte auf jeden Fall keine).

Bei Linux Programmen ist mir das noch nicht untergekommen. Mag natürlich auch daran liegen dass ich selbst kaum mit Linux arbeite