Seltsame Beschädigungen beim Speichern von Textpad 5 in Windows 7-64 VirtualBox VM in gemeinsam genutzten Ordnern mit Mac-Host

910
jlarson

Ich habe eine relativ neue Windows-7-64-Bit-Installation, die in Virtual Box auf einem MacBook Pro ausgeführt wird. Ich verwende TextPad 5 in dieser Umgebung, um Quelldateien zu bearbeiten, die sich in einem freigegebenen Ordner auf dem Mac Host befinden. Wenn ich einige dieser Quelldateien speichere, endet die gespeicherte Datei mit einem Teil oder mehrmals am Ende der Datei. Zum Beispiel eine Datei, die das am Ende hat:

 ... return ttp; };

würde sich nach dem Speichern mit öffnen:

 ... return ttp; };  };

Es ist definitiv ein Problem mit der Art und Weise, wie die Datei geschrieben wird, im Gegensatz zu der Art, wie sie gelesen wird, denn ich kann jetzt sehen, mit welcher App ich die Datei öffne (NotePad & Word in Windows 7, TextWrangler wieder im Mac).

Ich habe versucht, als ANSI und UTF-8 zu speichern, und mit oder ohne "Unicode- und UTF-8-BOM schreiben" in den TextPad-Einstellungen geprüft. Es passiert nicht bei allen Dateien, obwohl ich kein Muster darüber sehe, welche Dateien das Problem haben oder nicht haben. Dies geschieht nicht bei Dateien, die auf das Windows 7-Laufwerk c: \ geschrieben werden. Und bisher passiert es nicht bei anderen Anwendungen, die Dateien speichern, sondern nur TextPad.

Irgendwelche Ideen?

Meine Versionen:

  • Textpad 5.4.2
  • Windows 7 Professional 64-Bit, auf dem neuesten Stand
  • VirtualBox 4.0.8 r71778
  • OSX 10.6.7
0
Nur um klar zu sein, der freigegebene Ordner auf dem Host befindet sich auf einer HFS +-formatierten Partition. Goyuix vor 13 Jahren 0
@Goyuix - Ja, der freigegebene Ordner befindet sich auf meiner OSX-Partition, und ich glaube, dass HFS + das Standardformat dafür ist, obwohl ich nicht sicher bin, wie ich das überprüfen kann ... jlarson vor 13 Jahren 0
Ich habe zu Notepad ++ gewechselt, was ich ernsthaft minderwertig finde, jedoch hat es dieses Korruptionsproblem nicht. Glücklicherweise ist der größte Teil meiner Entwicklungsarbeit in der OSX-Welt zu Ende. Notepad ++ reicht aus. jlarson vor 13 Jahren 0

1 Antwort auf die Frage

0
Goyuix

Das klingt wirklich nach einem Fehler in TextPad - ich kann mir nichts vorstellen, was VirtualBox tun würde, was dazu führen würde, dass es sich so verhält. Die Funktion von Shared Folders ordnet Ihrem Windows 7-Gast grundsätzlich ein falsches Netzlaufwerk zu. Wenn VirtualBox das seltsame Verhalten eingeführt hat, sollten Sie es in allen anderen Apps sehen.

Ich habe gesehen, dass sich eine Reihe von Programmen beim Speichern von Dateien schlecht verhalten hat, vor allem, weil sie den Inhalt der vorhandenen Datei überschreiben, ohne die Dateilänge zurückzusetzen oder die Bytes am Ende auf Null zu setzen. Dies bedeutet, dass Sie, wenn Sie Ihre Datei "verkürzen", indem Sie einige Zeichen oder Zeilen entfernen, genau das oben beschriebene Verhalten erhalten. Sie könnten sicherlich ein paar Tests durchführen, um die Ursache des Problems genau zu bestimmen, und die Autoren dazu verwenden, die Fehler zu beheben:

  • Können Sie das Verhalten mithilfe von "Speichern unter" statt nur "Speichern" replizieren?
  • Können Sie das Verhalten replizieren, indem Sie die Datei kürzer machen? länger?
  • Können Sie das Verhalten auf anderen Netzlaufwerken replizieren? oder einfach nur freigegebene Ordner-Funktionen?
  • Könnten andere "Filter" Auswirkungen auf den Speichervorgang haben, z. B. Virenschutz, Schritte nach dem Build, Quellcodeverwaltung usw.

Zur Demonstration mit PowerShell können Sie dasselbe Verhalten replizieren, das Sie sehen. Ich begann damit, den ersten Absatz von A Tale of Two Cities zu nehmen und als tale.txt zu speichern

$text = gc tale.txt $fs = [System.IO.File]::OpenWrite("tale.txt") $sw = New-Object System.IO.StreamWriter($fs) $sw.Write($text.Replace("the","")) $sw.Dispose()

Sie sehen, dass alle 15 Instanzen der Wörter "the" wie beabsichtigt durch die leere Zeichenfolge ersetzt wurden, wobei die unbeabsichtigten Folgen der letzten 45 Bytes der ursprünglichen Datei übrig blieben und der Satz "nur im überdurchschnittlichen Vergleichsgrad " wiederholt wurde . "zweimal am Ende der Datei - ähnlich der oben beschriebenen Situation.

Der Vollständigkeit halber sollte für das obige Beispiel für den fehlerhaften Code die OpenWrite-Methode nicht verwendet werden, sondern die statische WriteAllText-Methode für die File-Klasse.

Tolles Zeug. 1) Mit Save-As wird das Problem nicht reproduziert. 2) kürzer oder länger oder überhaupt keine Änderung - all dies führt zum Problem. Die Menge des replizierten Texts und die Anzahl der replizierten Texte ändern sich jedoch je nach. Ich kann das Muster nicht erkennen, aber es gibt eins ... 3) Nein, kann nicht auf einem Netzlaufwerk oder auf dem (virtuellen) Laufwerk C: \ repliziert werden. 4) Es sind keine anderen Filter beteiligt, dies ist ein brandneues System, und ich bin zuversichtlich. Zu Nr. 1 - Nach dem erneuten Öffnen der Datei, die ich mit "Speichern unter" erstellt hatte, und erneutem Speichern (in den freigegebenen Ordner), besteht trotz identischem Inhalt kein Problem jlarson vor 13 Jahren 0
... und in Bezug auf # 1 ist es noch wilder, wenn ich die Save-As-Datei nehme, die das Problem * nicht * reproduziert, und es über dem Namen speichern, der ein Problem hat, dann ist das Problem wieder da. Mit anderen Worten, stellen Sie sich vor, A) öffne "1.txt" B) speichern Sie es C) öffnen Sie es erneut und sehen Sie Problem D) Problem beheben und speichern unter "1b.txt" E) "1b.txt" erneut öffnen, kein Problem F ) speichern Sie "1b.txt" G) erneut, öffnen Sie "1b.txt" erneut und sehen Sie kein Problem. H) save-as "1b.txt" bis "1.txt". I) öffne "1.txt" J) das Problem ist da !! .... fühlt sich an wie schlechte Sektoren oder sowas, gibt es so etwas mit einem gemeinsamen Laufwerk? jlarson vor 13 Jahren 0

Verwandte Probleme