Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a fairly new Window-7 64bit install running in Virtual Box on a MacBook Pro. I'm using TextPad 5 within that environment to edit source files that live on a shared folder that is on the Mac Host. When I save some of these source files, the saved file ends up with some amount of the end of the file repeated one or more times. For example, a file that has this at the end:

    return ttp;

would, once saved, open up with:

   return ttp;


It is definitely a problem with how the file gets written as opposed to how it's read, because I can see this now matter what app I use to open the file with (NotePad & Word in Windows 7, TextWrangler back in the Mac).

I've tried saving as ANSI and UTF-8, and with or without the 'Write Unicode and UTF-8 BOM' checked in TextPad preferences. It doesn't happen with all files though I can't see any pattern about which files do or don't have the problem. It doesn't happen with files written to the Windows 7 c:\ drive. And so far it doesn't happen from other applications saving files, only TextPad.

Any ideas?

My versions:

  • Textpad 5.4.2
  • Windows 7 Professional 64-bit, fully up to date
  • VirtualBox 4.0.8 r71778
  • OSX 10.6.7
share|improve this question
Just to be clear, the shared folder on the host resides on an HFS+ formatted partition? – Goyuix Jun 25 '11 at 4:21
@Goyuix - yes, the shared folder is on my OSX partition, and I believe that HFS+ would be the default format of that though I'm not sure how to check... – jlarson Jun 25 '11 at 14:56
I've switched to Notepad++, which I find seriously inferior, however it does not have this corruption problem. Fortunately most of my dev work is over in OSX world so Notepad++ will suffice. – jlarson Jul 6 '11 at 19:57

This really sounds like a bug in TextPad - I can't think of anything VirtualBox would be doing that would cause it behave this way. The way Shared Folders work, it basically maps a fake network drive to your Windows 7 guest. If it was VirtualBox introducing the strange behavior you should see it manifested in all other apps.

I have seen a number of programs misbehave when saving files before, primarily in how they basically just overwrite the contents of the existing file without actually resetting the file length, or zero'ing out the bytes at the end. What this means is that if you "shorten" your file by removing a few characters or lines, you get the exact behavior described above. You could certainly perform a few tests to really nail down the source of the problem, and use that to get the authors to fix the bugs:

  • Can you replicate the behavior using Save-As instead of just Save?
  • Can you replicate the behavior by making the file shorter? longer?
  • Can you replicate the behavior on other network drives? or just Shared Folders features?
  • Could any other "filters" be impacting the save operation, e.g. anti-virus, post-build steps, source control, etc.

As a demonstration, using PowerShell - here is how you can replicate the same behavior you are seeing. I started by taking the opening paragraph of A Tale of Two Cities and saving it as tale.txt

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

You can see that all 15 instances of "the" words have been replaced by the empty string as intended, with the unintended consequence of the last 45 bytes of the original file remaining, thus repeating the phrase "in the superlative degree of comparison only." twice at the end of the file - similar to the situation you describe above.

For completeness, the simple solution to the bad-code example above is to not use the OpenWrite method and instead call the static WriteAllText method on the File class.

share|improve this answer
Great stuff. 1) Save-As does not reproduce the problem 2) shorter or longer, or no change at all - these all make the problem happen. The amount of text replicated and how many times it's replicated changes depending though. I can't spot the pattern but there is one... 3) No, can't replicated on a network drive or on the (virtual) C:\ drive. 4) No other filters are involved, this is a brand new system and I'm confident of that. Regarding #1 - After re-opening the file that I created via Save-As, and Save-ing it again (to shared folder), it doesn't have a problem, despite identical content – jlarson Jun 28 '11 at 15:43
...and regarding #1, even more wild is that if I take the Save-As file which is not reproducing the problem, and save it over the name which is having a problem, then the problem is back. In other words, imagine A) open "1.txt" B) save it C) reopen it and see problem D) correct problem and save-as to "1b.txt" E) reopen "1b.txt", no problem F) save "1b.txt" G) again, reopen "1b.txt" and see no problem H) save-as "1b.txt" to "1.txt". I) open "1.txt" J) the problem is there!! .... feels like bad sectors or something, is there such a thing w/ a shared drive? – jlarson Jun 28 '11 at 15:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .