Hi Andrew,

Yes, I know better than to let that happen but goofed this time by looking at the free space at the beginning of the destination path without realizing that one of the sub-directories linked back to another partition. But I think it's not as bad as I made it sound: actually, the whole file was on the disk before the other process filled it up, then I tried to add a bit to the file and that's all that apparently wouldn't save. I really like GNU/Linux and have tried to use it exclusively for quite awhile now. Xfce is a newer thing for me, and while it's never sluggish, I'm missing several little conveniences and am generally surprised that its simplicity does not seem to add stability. But this seems like a particularly nasty bug in it's editor Mousepad. I'm not surprised it failed to save my additions to the file while the disk was full, but it certainly should fail more gracefully than to truncate the file to nothing.
I guess it's good I avoided this situation so long but now I'm a total noob at any recovery or file carving tools so I really appreciate your advice. I have found several blocks of the emptied file by remembering bits of the file and greping for them in the strings in the partition's unallocated space but I'm hoping there's a more deterministic way to know I've got all the blocks that were associated with that file just before Mousepad wiped it. I think this would make a good case study: mangled version of a file was save over the good version, how do I get (as much as possible of) the previous version back? I'd be happy to type up a step by step guide and submit it if I can figure it out.
Hopefully this won't be (isn't already!) too long, here's what I've tried:

I know some of what's in the file so I tried using the guide at:

http://wiki.sleuthkit.org/index.php?title=FS_Analysis

I think this worked to extract the unallocated (deleted) blocks from the partition:

sudo dls /dev/sda1 >unallocated

And then I extracted all of the ASCII strings:

strings -t d unallocated >unallocatedStrings

Then I searched for a bit of text I know is in the file:

grep "could have a standardized area on every" unallocatedStrings

122049160 SO, could have a standardized area on every page

But then they use fsstat to see the "fragment size" but the word fragment appears nowhere in the output of:

fsstat /dev/sda1

it does say the partition is formatted as ext3, has an inode range of 1 - 732960, a block range of 0 - 2929845, a block size of 4096, 90 block groups, 8144 inodes/group, 32768 blocks/group, and the journal inode is 8.

Can the journal be used to see what happened to this text file recently?

Or can I use that byte offset to find the blocks of the file to put back together?
122049160 / 4096 = block 29797

So by greping around like this, I've found 15-20 blocks so a lot of it is definitely recoverable but I doubt I can remember some bit of text from each block.

Can I do something with these block numbers to find associated blocks?

Here's what else I tried, but no good results:

And although my drive has no hardware issues, I imaged the partition the file is on with:

ddrescue --no-split /dev/sda1 imagefile log

(which reported no errors) so I could try the same thing using the Sleuthkit guide the Ubuntu Rescue Remix Documentation link points to:

https://help.ubuntu.com/community/DataRecovery

But fls finds only the existing file:

fls imagefile -r |grep lost-file
++++++ r/r 117099: lost-file.txt
++++++ r/r 117274: lost-file-old.txt

And icat shows it's empty:

icat -r imagefile 117099
(outputs nothing)

Also tried foremost but it doesn't seem to collect text files, or does it put them under htm or something?

Any suggestions on how to proceed are appreciated.

Thanks,
Mike