Announcement: there is an English version of this forum on 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
Peter G. schrieb: > Dann sehe ich erst eine Meldung, dass das Format nicht passt und wähle > ein anderes Format. Tolle Beschreibung. Hilft enorm.
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.
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.
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?
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
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
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...
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.
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.
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.
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.
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.
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.
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
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. !!!
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.
Angehängte Dateien:
-
Bildschirmfoto.png
28 KB
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.
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
🐧 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.
🐧 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?
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.
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.
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.
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.
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.
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.
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.
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).
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.