Kopieren und Synchronisieren von großen Dateien auf FAT32

German support forum

Moderators: Hacker, Stefan2, white

Post Reply
Macher
Junior Member
Junior Member
Posts: 18
Joined: 2005-11-28, 17:33 UTC
Location: Deutschland

Kopieren und Synchronisieren von großen Dateien auf FAT32

Post by *Macher »

Hi und allen frohe Festtage!

Ich hab mal einen neuen Thread eröffnet, ausgehend von dem doch ein wenig vom Thema abhanden gekommenen Thread "Probleme beim kopieren von große Dateien auf FAT32"

Nicht selten passiert es auch mir daß eine zu große Datei (also 2 oder 4 GByte und mehr) nicht auf ein Volume mit FAT16 oder FAT32 kopiert werden konnte.
Ich nutze auch z.B. sehr häufig die Synchronisierungsfunktion von TC.
Oftmals habe ich mir den Wunsch laut vor sich hingedacht, aber diesmal schreib ich ihn auch rein:

TC soll bei Kopieroperationen aller Art eine bequeme Option anbieten, die Datei gleich aufsplitten zu können.

Diese Option kann entweder in den Konfigurationen voreingestellt sein und/oder der User wird während des Kopierens bei Auftreten der Fehlermeldung gefragt, ob TC die Datei in kleinere Portionen aufsplitten darf.


In diesem Zusammenhang ist es für mich auch sehr wünschenswert, daß bei der Synchronisierung von unterschiedlich formatierten Volumes ein solcher Sonderfall berücksichtigt wird.
Angenommen, ich habe ein NTFS-Volume, und habe die Dateien auf ein (i.d.R. externes) FAT32-Volume gesichert (z.B. USB-Stick mit 64 KByte).
Alle übergroße Dateien wurden beim Synchronisieren übersprungen und diese habe ich zusätzlich manuell mit der Dateien aufsplitten Funktion von TC auf das FAT32-Volume aufgesplittet. (also mit den Endungen 001, 002, usw.)
Diese aufgesplitteten Dateien werden bei einer späteren, erneuten Synchronisierung natürlich als "ungleich" im Vergleich zur Original-Datei beanstandet.
Im Laufe der Zeit sind bei mir schon etliche solcher Sonderfälle dazugekommen, so daß beim Synchronisieren immer mehr unnötige zusätzliche Handarbeit vonnöten ist.

Daher mein zweiter Wunsch, aufbauend auf den ersten: Meiner Meinung nach ist es durchaus einfach möglich die Synchronisierungsfunktion um die intelligente Erkennung dieses Sonderfalls zu erweitern.
Ggf. bekommen die so erkannten Dateien eine andere Hintergrundfarbe um auf diesen Sonderfall hinzuweisen.
Natürlich sollen die aufgesplitteten Dateien das gleiche Dateidatum und -zeit haben wie die Originaldatei. Was bei einer Synchronisierung auch Sinn machen würde.

Ich hoffe, daß ich nicht alleine dastehe mit meinen beiden Wünschen?

Martin
User avatar
gian
Member
Member
Posts: 106
Joined: 2010-06-01, 09:14 UTC
Location: ZH
Contact:

Post by *gian »

Hallo,

Ich wünsche diese Aufsplittung nicht, weil auch meine kleinsten USB-Sticks nicht mehr mit FAT16 und FAT32 formatiert sind. So war auch das Kopieren von 2 Dateien (12GB und 9GB gross) auf einen 32GB Stick für TC absolut kein Problem, auch was die Zeit dazu betrifft.

Warum soll man USB-Sticks noch mit 16 bzw. 32 FAT formatieren. Meine NTSF-Disks kann ich übrigens auch problemlos anschauen, wenn ich mittels USB-Diskettenlaufwerk und DOS-Bootdiskette (DOS mit NTFS-Unterstützung) boote (aus Nostalgiegründen ;).

Warum also TC mit Features versehen, die kaum benötigt werden - auch mein Fahrrad hat schliesslich keine Holzräder mehr!

Gruss

Gian
User avatar
Dalai
Power Member
Power Member
Posts: 9988
Joined: 2005-01-28, 22:17 UTC
Location: Meiningen (Südthüringen)

Post by *Dalai »

gian wrote:Ich wünsche diese Aufsplittung nicht, weil auch meine kleinsten USB-Sticks nicht mehr mit FAT16 und FAT32 formatiert sind.
Wenn deine Sticks kein FAT verwenden, wo tangiert dich dann dieser Wunsch bzw. dessen etwaige Umsetzung? TC sollte die Entscheidung, ob zu splitten ist, anhand des Dateisystems treffen und nicht anhand des Zieltyps (USB-Stick, CF-Karte o.ä.).
Warum soll man USB-Sticks noch mit 16 bzw. 32 FAT formatieren.
Jedes Journaling-Dateisystem wie NTFS, ext3 usw. schreibt häufiger auf ein Medium als ein Non-Journaling-Dateisystem. Flashspeicher mit einem Journaling-Dateisystem zu formatieren, verschleißt diese Medien schneller als bei FAT(32) der Fall, weil die Anzahl der Schreibzyklen begrenzt ist.

MfG Dalai
#101164 Personal licence
Ryzen 5 2600, 16 GiB RAM, ASUS Prime X370-A, Win7 x64

Plugins: Services2, Startups, CertificateInfo, SignatureInfo, LineBreakInfo - Download-Mirror
Moon
Member
Member
Posts: 195
Joined: 2003-09-12, 07:41 UTC

Post by *Moon »

gian wrote:Warum soll man USB-Sticks noch mit 16 bzw. 32 FAT formatieren.
Weil das Autoradio keinen mit NTFS formatierten lesen kann und man gerne nur einen Stick statt mehrere nutzen will?
User avatar
Sir_SiLvA
Power Member
Power Member
Posts: 3381
Joined: 2003-05-06, 11:46 UTC

Post by *Sir_SiLvA »

Wer hat den 4GB große MP3s fürs Autoradio?
Hoecker sie sind raus!
Moon
Member
Member
Posts: 195
Joined: 2003-09-12, 07:41 UTC

Post by *Moon »

Was war jetzt an dem EINEN Stick, der neben MP3s natürlich auch größerere Dateien anderen Formats speichert, so schwer zu verstehen?
User avatar
gian
Member
Member
Posts: 106
Joined: 2010-06-01, 09:14 UTC
Location: ZH
Contact:

Post by *gian »

Moon wrote:
gian wrote:Warum soll man USB-Sticks noch mit 16 bzw. 32 FAT formatieren.
Weil das Autoradio keinen mit NTFS formatierten lesen kann und man gerne nur einen Stick statt mehrere nutzen will?
Alles klar, nur deswegen kaufe ich mir kein Auto :lol:
User avatar
Sir_SiLvA
Power Member
Power Member
Posts: 3381
Joined: 2003-05-06, 11:46 UTC

Post by *Sir_SiLvA »

Moon wrote:Was war jetzt an dem EINEN Stick, der neben MP3s natürlich auch größerere Dateien anderen Formats speichert, so schwer zu verstehen?
Was ist daran so SCHWER zu verstehen und MERKEN das ein FAT-Stick eben NICHT größere Dateien speichern kann? :P
Hoecker sie sind raus!
Moon
Member
Member
Posts: 195
Joined: 2003-09-12, 07:41 UTC

Post by *Moon »

4 GB sind also klein? Ja ne, is klar.
Tiggaa
Member
Member
Posts: 151
Joined: 2007-06-15, 21:27 UTC

Post by *Tiggaa »

Wie wäre es mit dem ablegen einer kleinen Txt Datei auf so nem Fat32 Stick in der drin steht: Dieser Stick kann eine Datei größer als 4,1*** Gigabyte nicht in einem Stück abspeichern.
Kann dann bei schwerer Vergesslichkeit und oder Hippeligkeit nachgelesen werden. Zur Not wäre evt sogar noch folgende Erweiterung möglich: Es ist daher ein/der ntfs formatierte(r) zu verwenden.

Und für ganz vergessliche der Zusatz: Der liegt normalerweise rechts in der obersten Schreibtischschublade. :lol:

Zurück zum Thema: Ich verstehe die Anfrage nach einer auf so einem Stick bitteschön machbaren Dateisystem-erkennung und ein entsprechendes automatisiertes anbieten einer Splitfunktion durchaus.

Der Grund für mich ist aber ein, soweit ich das sehe, hier noch nicht genannter: Der Wechsel von fat32 auf ntfs führt bei so manchen Sticks zu einem eklatanten Lese und Schreibgeschwindigkeitseinbruch.
Von daher wäre eine automatisierte Aufklärung bzw. Abklärung ob Splitting für den Benutzer in Frage kommt evt. tatsächlich ein sinniges Feature.
Ich für mich lege aber nicht wirklich Wert auf die Existenz von sowas im TC.
Post Reply