Forum: PC Hard- und Software Ubuntu: Textdatei hat plötzlich 0 Byte :-(


von Peter G. (Gast)


Lesenswert?

Hallo,

habe auf einem Notebook ein Ubuntu (XUbuntu) eingerichtet und darauf 
zusätzlich ein WinXP. Ab und zu greife ich aus Ubuntu auf eine von WinXP 
erzeugte *.txt Datei zu. Dann sehe ich erst eine Meldung, dass das 
Format nicht passt und wähle ein anderes Format. Dann lässt sich die 
Datei öffnen, beschreiben und speichern.

Heute nun passiert (wie schon einmal) ein seltsamer Fehler: Beim 
Abspeichern sehe ich die Meldung (sinngemäß) "nicht möglich, weil von 
dritter Seite zugegriffen wird oder wurde". Nach der Meldung ist es aber 
dann schon passiert, die Datei hat 0 Byte (auch unter Windows). So ist 
mir heute eine temporäre Linksammlung verloren gegangen :-(

Was ist da los und wie kann man das verhindern?
Das geht 100 mal gut und dann folgt die Katastrophe.

Peter

von Wendels B. (wendelsberg)


Lesenswert?

Peter G. schrieb:
> Dann sehe ich erst eine Meldung, dass das Format nicht passt und wähle
> ein anderes Format.

Tolle Beschreibung. Hilft enorm.

von Data Backer (Gast)


Lesenswert?

Peter G. schrieb:
> So ist
> mir heute eine temporäre Linksammlung verloren gegangen :-(

Wenn man keine Backups seiner Daten hat dann sind sie einem
wohl nichts Wert gewesen. Keine Runde Mitleid für dich.

von Peter D. (peda)


Lesenswert?

Peter G. schrieb:
> So ist
> mir heute eine temporäre Linksammlung verloren gegangen :-(

D.h. Du gehörst zu den vielen Unbelehrbaren, die meinen, Backups sind 
nur was für Warmduscher.

Temp-Verzeichisse werden vom OS extra dafür eingerichtet, daß es darin 
ab und zu mal aufräumen darf. Damit will man vermeiden, daß Laufwerke 
zugemüllt werden. Sachen, die man behalten will, gehören da auf keinen 
Fall hin.

von Wasistdas (Gast)


Lesenswert?

Peter G. schrieb:
> So ist
> mir heute eine temporäre Linksammlung verloren gegangen

Was bitteschön ist eine "temporäre Linksammlung"?
Wo hast du das gespeichert?

von Daniel A. (daniel-a)


Lesenswert?

Peter G. schrieb:
> Dann sehe ich erst eine Meldung, dass das
> Format nicht passt und wähle ein anderes Format.

Und welches Programm verwendest du da? Ein plain text Editor wie z.B. 
kate, kwrite, geany, gedit, emacs, nano oder vi, etc. würde sowas nicht 
machen.

Und wo liegt die Datei? Falls auf einem NTFS Laufwerk, davon würde ich 
abraten. Zum Austausch von Daten zwischen Windows & Linux würde ich eher 
UDF oder FAT & eine separate Partition nehmen. Bei NTFS kann man sich 
nur unter Windows sicher sein, dass das einigermassen zuverlässig läuft. 
Es gäbe zwar auch noch Treiber für ext4 usw. für Windows, aber ich weiss 
nicht, wie zuverlässig die laufen.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

NTFS-Partionen auf Dual-Boot-Systemen unter Linux read-write zu mounten,
ist riskant, wenn man nicht genau weiß, was man tut. Hast du die Punkte
im folgenden Artikel (insbesondere diejenigen im roten Kasten) beachtet?

  https://wiki.ubuntuusers.de/Windows-Partitionen_einbinden/NTFS-3G/#Dual-Boot-und-Ruhezustand-Hibernate

Wasistdas schrieb:
> Was bitteschön ist eine "temporäre Linksammlung"?

Eine, die nur zeitlich begrenzt existiert und irgendwann wieder
verschwindet, so wie beim TE geschehen ;-)

: Bearbeitet durch Moderator
von Wasistdas (Gast)


Lesenswert?

Yalu X. schrieb:
>> Was bitteschön ist eine "temporäre Linksammlung"?
>
> Eine, die nur zeitlich begrenzt existiert und irgendwann wieder
> verschwindet, so wie beim TE geschehen ;-)

Ja schon. Mir geht es darum, was der TO damit meint...

von Paul (Gast)


Lesenswert?

Peter D. schrieb:
> D.h. Du gehörst zu den vielen Unbelehrbaren, die meinen, Backups sind
> nur was für Warmduscher.

Ich hab mir damals mal einen Satz eingeprägt:
"Datensicherung ist Mangel an Vertrauen."
(...und zwar ironisch gemeint!)
Einige Leute vergessen scheinbar die ironische Bedeutung.

von Klaus S. (kseege)


Lesenswert?

Peter G. schrieb:
> Was ist da los und wie kann man das verhindern?

Los ist wahrscheinlich, daß ein Bug in Ubuntu steckt.
Verhindern kann man das, indem man nicht das Original überschreibt, 
sondern eine Kopie erzeugt. Erst wenn die erfolgreich geschrieben wurde, 
löscht man das Original.

Im Übrigen sind die Daten wohl noch auf der Platte. Ein Programmierer 
würde sich jetzt Block für Block mit "dd" von der Platte holen und eine 
Stringsuche nach einem noch in der Erinnerung gebliebenen Wort aus der 
Datei machen.

Außerdem gibt es Spezialprogramme für diesen Zweck, gelöschte Dateien 
wiederzufinden. Recuva und ddrescue fallen mir spontan ein. Da ist dann 
googeln und Nachdenken angesagt. Manchmal hilft auch das einfache 
Hochsetzen der Dateilänge und alles ist wieder da. Damit kann man aber 
Folgeschäden anrichten, daher zur Sicherheit auf eine andere Partition 
kopieren und danach die Länge wieder auf 0 setzen.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Früher, als ich noch etwas mehr mit Windows am Hut hatte, mountete ich
die NTFS-Partition(en) von Windows unter Linux read-only und die
ext*-Partition(en) von Linux unter Windows ebenfalls read-only. Damit
hatte ich alle Möglichkeiten, Dateien zwischen den beiden OS
auszutauschen, dennoch wird jede Partition nur von dem OS beschrieben,
zu dem sie auch gehört. Damit war Datenverlust auf Grund von Fehlern in
den Dateisystemtreibern oder den in meinem letzten Beitrag verlinkten
Artikel genannten Problemen so gut wie ausgeschlossen.

Insbesondere der NTFS-Treiber unter Linux war kritisch, weil Microsoft
keine Spezifikation von NTFS veröffentlichte, so dass nicht garantiert
werden konnte, dass wirklich alle Details richtig umgesetzt wurden.

Ich weiß nicht, ob diese Spezifikation mittlerweile verfügbar ist. Wenn
nicht, würde ich nach wie vor vom Beschreiben von NTFS-Partitionen unter
Linux abraten.

von Peter D. (peda)


Lesenswert?

Klaus S. schrieb:
> Manchmal hilft auch das einfache
> Hochsetzen der Dateilänge und alles ist wieder da.

Neben der Dateilänge braucht man ja noch den Verweis, wo die Daten 
stehen und der dürfte bei Länge 0 nicht mehr existieren.
NTFS kann kleine Dateien (Batch Aufrufe) gleich mit im 
Verzeichniseintrag anlegen. FAT belegt zwingend mindestes einen weiteren 
Cluster, auch wenn die Datei nur aus einem Byte besteht.

von Nano (Gast)


Lesenswert?

Daniel A. schrieb:
> Und wo liegt die Datei? Falls auf einem NTFS Laufwerk, davon würde ich
> abraten. Zum Austausch von Daten zwischen Windows & Linux würde ich eher
> UDF oder FAT & eine separate Partition nehmen. Bei NTFS kann man sich
> nur unter Windows sicher sein, dass das einigermassen zuverlässig läuft.
> Es gäbe zwar auch noch Treiber für ext4 usw. für Windows, aber ich weiss
> nicht, wie zuverlässig die laufen.

Ich tausche jetzt schon seit Jahren über NTFS Dateien zwischen Linux und 
Windows und habe da noch nie Probleme gehabt, seitdem das von den 
Distributionen offiziell unterstützt wird.

Früher hatte ich eine extra vfat Partition dafür, aber das ist nun jetzt 
schon über ca. 20 Jahre her.

NTFS kann man also, sofern man keine besonders ausgefallenen Features 
von NTFS nutzt, problemlos nutzen. Auch mit schreibendem Zugriff von 
Linux aus.

von c-hater (Gast)


Lesenswert?

Nano schrieb:

> Ich tausche jetzt schon seit Jahren über NTFS Dateien zwischen Linux und
> Windows und habe da noch nie Probleme gehabt, seitdem das von den
> Distributionen offiziell unterstützt wird.

Geht mir genauso.

> NTFS kann man also, sofern man keine besonders ausgefallenen Features
> von NTFS nutzt, problemlos nutzen. Auch mit schreibendem Zugriff von
> Linux aus.

Ja. Man muss bloß auf eine Sache achten: diesen "Schnellstart", der seit 
Windows10 default ist, abzuschalten. Sonst sind Probleme natürlich 
vorprogrammiert.

von Klaus S. (kseege)


Lesenswert?

c-hater schrieb:
> Ja. Man muss bloß auf eine Sache achten: diesen "Schnellstart", der seit
> Windows10 default ist, abzuschalten. Sonst sind Probleme natürlich
> vorprogrammiert.

Natürlich!
Als Administrator: powercfg /hibernate off

von Schlaumaier (Gast)


Lesenswert?

Peter G. schrieb:
> "nicht möglich, weil von
> dritter Seite zugegriffen wird oder wurde".

Unter Windows dein Taskmanager starten und den Prozess killen.

ABER, wenn diese Meldung auftaucht ist die 1 + sicherster Lösung die 
Datei einfach unter ein anderen Namen zu speichern.

Ob Linux o. Windows ist aber egal. Bei Fehlermeldungen einfach IMMER 1 
Lösung unter anderen Namen speichern. !!!

von Peter G. (Gast)


Lesenswert?

Wasistdas schrieb:
> Was bitteschön ist eine "temporäre Linksammlung"?

Wenn ich im Netz etwas komplexeres suche, kopiere ich 
erfolgversprechende Links in eine Textdatei. Meist finde ich dann 
irgendwann das passende (Volltreffer), dann können die 
erfolgversprechenden Links in die Tonne. Und hier ist mir beim Versuch, 
einen neuen Link zu speichern, die Datei auf Null Byte gesetzt worden.

Nebenbei kann ich auch nicht mitten in meiner Suche ein Backup machen.
Bemerkungen wie:

Data Backer schrieb:
> Wenn man keine Backups seiner Daten hat dann sind sie einem
> wohl nichts Wert gewesen. Keine Runde Mitleid für dich.

gehören in den Kindergarten.

von Peter G. (Gast)


Angehängte Dateien:

Lesenswert?

Daniel A. schrieb:
> Und welches Programm verwendest du da? Ein plain text Editor wie z.B.
> kate, kwrite, geany, gedit, emacs, nano oder vi, etc. würde sowas nicht
> machen.

Nennt sich Mousepad, ist wohl das Pedant zu "Editor", was bei Windows 
schon immer mit dabei ist. Mousepad war wohl nach der Installation von 
Ubuntu mit an Bord.

> Und wo liegt die Datei?

Unter Windows, Partition D:

> Falls auf einem NTFS Laufwerk

Nö, ist FAT32

Habe mal versucht, das Ganze erneut zu provozieren:

Also eine *.txt Datei unter Windows erzeugt und paar Worte rein 
geschrieben. Dann Ubuntu gebootet und die Datei aufgerufen. Diese 
Auswahlbox (Bild) erscheint zu meinem Erstaunen nicht.

Also nochmal zurück zu Windows und eine andere Linksammlung kopiert. 
Wieder Ubuntu gebootet und nun erscheint diese Auswahlbox (Bild). Ich 
klicke - wie immer - auf "Andere", dann erscheint der Text und ich kann 
wie im Windows "Editor" die Texte bearbeiten oder Inhalte aus der 
Zwischenablage hinzufügen und speichern. Klappte diesmal einwandfrei. 
Genau hier (beim Versuch zu speichern) erschien die Meldung von dem 
Zugriff von 3. Seite (sinngemäß). Danach hatte die Datei Null Byte.

Ich vermute, dass in den Links aus der Zwischenablage zu viele "wilde" 
Zeichenfolgen standen, die dann einen Fehler erzeugt haben.

Ein Workaround würde helfen, damit mir das nicht nochmal passiert.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Peter G. schrieb:
> Ab und zu greife ich aus Ubuntu auf eine von WinXP
> erzeugte *.txt Datei zu. Dann sehe ich erst eine Meldung, dass das
> Format nicht passt und wähle ein anderes Format.

Nach dem Bild im letzten Eintrag geht es da nicht um das Dateiformat 
(was hier wohl text/plain sin dürfte), sondern um die Zeichenkodierung. 
Normalerweise speilt das nur bei Umlauten & Sonderzeichen eine rolle. 
Windows XP konnte da glaube ich noch kein UTF-8, und speichert das in 
einer ANSI erweiterten Codierungen ab. Diese können, anders als UTF-8, 
nicht alle Zeichen codieren, aber der ASCII Bereich (siehe die erste 
Tabelle hier: https://tools.piex.at/ascii-tabelle/), also die ersten 128 
Zeichen, sind bei ASCII und UTF-8 gleich. Die anderen 128 Zeichen sind 
in ASCII übrigens nicht definiert, je nach ISO irgendwas Kodierung, für 
verschiedene Sprachen, stehen die für andere Zeichen. Bei UTF-8 wird 
satt einfach die restlichen 128 / 7 Bit Zeichenwerte zu nutzen, darin 
noch encodiert, ob die nächsten paar Bytes noch zum Code Point gehören, 
und dann gibt es noch Spezialzeichen zum Zusammensetzen von Zeichen usw. 
Der wichtige Punkt ist aber, dass da höchstens ein paar Spezialzeichen 
falsch interpretiert werden könnten. Bei Unicode gibt es noch gewisse 
Zeichen / Byte folgen, die ungültig sind, darum warnt Mousepad beim 
Lesen, wenn es merkt, dass bei den Spezialzeichen da was nicht passt.

Beim Speichern sollte sowas eigentlich auch höchstens dazu führen, dass 
halt die Zeichen fehlen, die die gewählte Encoding nicht repräsentieren 
kann (weil in dieser schlicht nicht vorhanden). Vielleicht hat Mousepad 
da ja einen Bug, und schreibt dann gar nichts? Passt zwar nicht wirklich 
zur geschilderten Fehlermeldung.

Es gibt auch noch die UTF-16 und UTF-32 Geschichten, wo minimal 2 Bytes 
ein Zeichen kodieren. Das ist nicht so kompatibel zu ASCII wie die UTF-8 
Sachen, aber scheint hier nicht relevant zu sein.

Peter G. schrieb:
> Danach hatte die Datei Null Byte

Achtung, null bytes haben und 0 bytes gross ist was komplett anderes. 0 
bytes gross heisst die Datei ist leer. Hat null bytes heisst es sind 
Zeichen mit dem wert 0 in der Datei.

Peter G. schrieb:
> Genau hier (beim Versuch zu speichern) erschien die Meldung von dem
> Zugriff von 3. Seite (sinngemäß).

Das ist extrem merkwürdig. Es gibt 2 Fehlercodes für locking 
Geschichten, die da einigermassen passen, EDEADLK und EDEADLOCK [1]. Es 
gibt diverse lockig Mechanismen bei Linux, und diese machen gebrauch von 
diesem Fehlercode beim locking selbst. Die Syscalls zum öffnen[2] und 
schreiben[3], können diesen Fehlercode aber nicht zurückgeben. (Ich habe 
auch nochmal im Kernel Code nachgesehen, für alle fälle. 
https://elixir.bootlin.com/linux/latest/source ist dafür extrem 
praktisch.). Das Mousepad Program scheint selbst kein locking bei 
Dateien zu machen[4]. Eigentlich sollte so ein Fehler also gar nicht 
möglich sein...

Schau eventuell mal in dmesg nach, ob da irgendwelche Fehler oder Stack 
Traces drin sind, und führe eventuell mal einen RAM check durch.

Falls es ein Wechseldatenträger ist, ist noch daran zu denken, diesen 
immer zu unmounten, damit die Daten auch alle geschrieben werden. 
Eventuell lönnte man noch die flush Option versuchen, damit die Daten 
schneller / häufiger auf die Disk zurückgeschrieben werden. Oder die 
sync mount option, damit alles immer sofort auf den Speicher geschrieben 
wird. Das wäre dann langsamer, aber man kann sich dann theoretisch das 
saubere Auswerfen / unmounten bei Wechseldatenträgern sparen.

1) https://man7.org/linux/man-pages/man3/errno.3.html
2) https://man7.org/linux/man-pages/man2/open.2.html
3) https://man7.org/linux/man-pages/man2/write.2.html
4) 
https://github.com/codebrainz/mousepad/blob/master/mousepad/mousepad-file.c#L709

von Peter G. (Gast)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Eigentlich sollte so ein Fehler also gar nicht möglich sein...
>
> Schau eventuell mal in dmesg nach, ob da irgendwelche Fehler oder
> Stack Traces drin sind, und führe eventuell mal einen RAM check durch.

OK, da der Fehler offensichtlich nicht bekannt ist, wird wohl ein 
anderes Problem vorliegen. Vor einigen Tagen tippte ich eben einen 
Beitrag hier im Forum, als ein Bluescreen mit der Meldung erschien 
(sinngemäß):

"Windows hat ein Problem festgestellt und muss beendet werden"

Boing - aus die Maus und der Beitrag natürlich futsch (ja ich weiß, 
selber schuld, kein Mitleid, warum hast du kein Backup gemacht). Danach 
hat das Notebook selbstständig neu gebootet und lief wieder einwandfrei. 
Auch das hatte ich im letzten Jahr schon mal.

Falls das "Zugriff von 3. Seite" Problem nochmal auftaucht, werde ich 
versuchen einen Screenshot auszulösen und hier posten.

von Guido B. (guido-b)


Lesenswert?

🐧 DPA 🐧 schrieb:
> Das Mousepad Program scheint selbst kein locking bei
> Dateien zu machen[4]. Eigentlich sollte so ein Fehler also gar nicht
> möglich sein...

Kann es nicht sein, dass zur Zeichenkonvertierung ein externes Tool
aufgerufen wird und dieses das Problem auslöst?

von Einer (Gast)


Lesenswert?

Peter G. schrieb:
> Vor einigen Tagen tippte ich eben einen
> Beitrag hier im Forum, als ein Bluescreen mit der Meldung erschien
> (sinngemäß):

Bluescreens bei "normalen" Anwendungen (Office, Browser, etc.) sind 
inzwischen ein ziemlich sicherer Indikator für Hardware-Defekte.

Hatte erst vor drei Wochen einen Notebook hier, der sporadisch (ein, 
zweimal am Tag) Bluescreens geworfen hat. RAM ausgetauscht, seitdem 
keine Probleme mehr.

von rbx (Gast)


Lesenswert?

Peter G. schrieb:
> Was ist da los und wie kann man das verhindern?

Sind wohl zwei Sachen, einmal das Text(abspeicher)-Format bzw. die 
Zeichenkodierung und das andere wohl wieder mal ein oller Bug.

Die Codierung selbst, bzw. die Endung des Dateicodes kann man auch per 
Editor bekommen. In Notepad++ (von Windows aus) hatte ich für Cygwin 
(und umgekehrt) diese Art von Konvertierung machen können.

Nun gibt es aber noch Festplattenkonvertierungen, und wie kompatibel 
sind die?

Man stelle sich folgendes vor: Auf einem Recher ist ein Windows 
installiert, auf einem anderen ein Linux, und man möchte öfter Daten 
austauschen. Hier ist man mehr auf der Linux-Seite gefordert, einen 
Kompromiss einzugehen. Auch die Software, bzw. die Arbeitsprogramme 
sollten für beide Systeme verfügbar sein.
Z.B. sind viele Spiele nur auf Windows zugeschnitten, und das ist Kacke. 
Manchmal bekommt man mit etwas Glück ein bestimmtes Spiel trotzdem auf 
Linux zum Laufen, manchmal auch nicht, und die (richtigen Leute), die 
auf reddit auf das Problem angesprochen werden, sagen dazu nur, mach 
doch dual-boot..

Zurück zum Kompromiss. Ein sehr guter Kompromiss ist, Dateien über 
Usb-Sticks zu tauschen. Usb-Sticks haben typischerweise 
FAT-Formatierung, und die kann Linux gut, das ist also (mittlerweile) 
gutes Übertragungsformat.
Auch NTFS geht seit einiger Zeit ganz gut (s.o.), da bleibt eigentlich 
nur ein Zeichenformat-Fehler.
Zumindest unter Windows kann man sich auch eine Partition zum Übertragen 
für eine Linux xyz-Formatierung machen. xyz für eines der typischen bzw. 
auch spannenden Formatierungsmöglichkeiten bei Linux.

https://de.wikipedia.org/wiki/Ext2

https://de.wikipedia.org/wiki/Byte-Reihenfolge

Jetzt noch was anderes oben drauf: diese Linux Ersatzeditoren für 
Notepad sind normalerweise nicht so gut (bzw. so universell) wie Notepad 
(in Windows) und kein Ersatz, auch wenn es von außen so aussieht. (!)
In Linux sollte man besser darauf hinarbeiten, Konsole-Editoren zu 
benutzen, oder eben bewährte Zwischenlösungen wie etwa SciTE oder den 
MC. Die Konsoledtitoren selber laufen ihrerseits ganz gut auf Windows.

von Bruno F. (Gast)


Lesenswert?

rbx schrieb:
> Usb-Sticks haben typischerweise FAT-Formatierung

USB-Sticks können in allen möglichen Formaten formatiert werden.
Zum Bleistift FAT, FAT32, exFAT, NTFS, ext2, ext4 und was es noch so 
alles gibt. Eine "typischerweise" Formatierung gibt es nicht. Auch im 
"Werkszustand" haben die verschiedene Formate. Die kleineren bekommt man 
oft mit FAT32, die größeren (ab 128GB?) meist mit exFAT.

von c-hater (Gast)


Lesenswert?

Bruno F. schrieb:

> USB-Sticks können in allen möglichen Formaten formatiert werden.
> Zum Bleistift FAT, FAT32, exFAT, NTFS, ext2, ext4 und was es noch so
> alles gibt.

Das ist erstmal korrekt, schließlich gibt es anders als z.B. bei 
SD-Cards keinen Standard, der diesbezüglich irgendwas vorschreibt.

> Eine "typischerweise" Formatierung gibt es nicht.

Naja, das ist dann doch etwas übertrieben. Ich habe noch keinen Stick 
gesehen, der ab Werk z.B. ein extN, HPFS oder UDF gehabt hätte, obwohl 
das alles technisch möglich wäre und gegen keinen Standard verstoßen 
würde.

> Auch im
> "Werkszustand" haben die verschiedene Formate. Die kleineren bekommt man
> oft mit FAT32, die größeren (ab 128GB?) meist mit exFAT.

Üblich sind FAT32 und ExFAT, wobei es keine fixen Grenzen bezüglich der 
Größe gibt. Bei geringen Größen überwiegt FAT32, bei größeren tendiert 
es hingegen immer mehr zu ExFAT. Aber auch NTFS kommt noch mit 
signifikanter Häufigkeit vor, erstaunlicherweise sogar bei relativ 
kleinen Sticks.

Tja, wenn es keinen geschriebenen Standard gibt, setzt halt das 
meistbenutzte Desktop-OS den Quasi-Standard. Logisch.

von Peter D. (peda)


Lesenswert?

c-hater schrieb:
> Üblich sind FAT32 und ExFAT

Ich formatiere sie immer auf NTFS um, da geht das Schreiben am 
schnellsten.
Bei FAT rödelt der sich zu Tode, besonders bei vielen kleinen Dateien.

von rbx (Gast)


Lesenswert?

Peter D. schrieb:
> Bei FAT rödelt der sich zu Tode, besonders bei vielen kleinen Dateien.

Hat der dann nicht eher eine Schraube locker? Bei mir blinken die immer 
nur.

von 🐧 DPA 🐧 (Gast)


Lesenswert?

Soweit ich weiss, ist einstellbar, ob Daten sofort geschrieben werden 
sollen, oder ob das im Hintergrund passiert, und und daten eventuell 
noch vorübergehend gecached werden. Unter Windows ist das bei USB FAT 
Sticks per default glaub ich so, dass das immer sofort geschrieben wird. 
Bei Linux ist der Default immer, nicht darauf zu warten (sync mount 
option). Aber eben, ist soweit ich weiss einstellbar. Der Stick selber 
wird vermutlich nicht schneller werden, nur weil man ein anderes FS 
verwendet.

von rbx (Gast)


Lesenswert?

Was mir noch einfällt, ist, dass durch Cygwin (max install) das 
Deframentieren der Festplatte von Windows Vista aufgrund der vielen 
kleinen Dateien immer viel länger brauchte. Meist so 2-3 Stunden, wenn 
wieder mal Gropßdefragmentierwoche war (oder so ähnlich).

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.