Daten kopieren/ Verschiedene Dateiträgerformate

Hi

Bin gerade ein wenig am Daten aufräumen.

Sollte es kein Problem sein z.B Daten mit Linux von einer Fat32 Festplatte auf eine NTFS Festplatte zu kopieren?

Können Dateien dadurch "kapput" gehen? Was muss ich beachten?

Die Daten sind schon wichtig nur habe ich keine Lust Tausende Dateien zu kontrollieren....

Bin mir nicht sicher nach welchen Stichwörtern ich suchen sollte.
Bin auch kein IT Experte.

(Sorry falls die Frage ein wenig blöd klingt...)

Gruss
luca

SeppJ

NTFS ist zu Fat32 abwärtskompatibel^*, bei einer Kopie von Fat32 zu NTFS kann also nichts verloren gehen. Viele Kopierprogramme bieten auch die Möglichkeit, die Dateien im Anschluss zu vergleichen, wenn du derart paranoid bist.

^*: Zumindest praktisch. Mag sein, dass es irgendwelche winzigen Detailsunterschiede gibt.

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.

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.