Can't open file - file manager error

Question

I can't open a couple files I was working on this afternoon. I shut down my computer when I left the office, now that I've booted again, when I try to open either of these 2 files I can a message that says "While attempting to access "file name" the file manager reported an error - 39."
I haven't made backups of these files, so that isn't an option.
I've rebooted a couple times, I've repaired disk permissions, but nothing works.
Previous files I worked on DO open correctly.
HELP! PLEASE!

Answer 1

I'm not sure if you have time to hold the hand of a "newbie" to Terminal
Of course! I'm always happy to introduce people to the command line
1) prompt$ - is my name bryceinman$
Most likely, yes. The default prompt usually contains the machine name, and sometimes the folder you are sitting in, and will usually end with a $ or a % (for a normal user), and typically a # for the root user.
2) cd - is that the name of the hard drive or do I just type "cd"
That is a command which means "c"hange "d"irectory (when you hear "directory", think "folder") and is how you move from one directory to another from the command line.
3) after that, it appears that I'm simply typing the path to the location of the file.
Yep.
Are you saying the "filename" will be the next string displayed by Terminal if, indeed, the file can >be found correctly? (Right now I'm getting the following: -bash: Macintosh: command not found)
That's correct. Once you've changed directories to the directory/folder that contains your problem file, you type at the prompt "ls -l filename", except that you will substitute the real file name for the word "filename" in my example.
And yes, using this same logic, the "cat filename > /dev/null" you will use the actual file name in place of "filename".
Maybe an example will help. Let's say I have a machine named tomservo, and a file called SmithDoc.txt, and it's located in my Documents folder, in a sub-folder called Work. To perform my above suggestions from the command line, I would do the following (I also show example output):
(Launch Terminal from Applications->Utilities)
tomservo$ cd Documents/Work
tomservo$
tomservo$ ls -l SmithDoc.txt
-rw-r--r-- 1 glsmith staff 512 Jun 10 22:01 SmithDoc.txt
tomservo$ cat SmithDoc.txt > /dev/null
tomservo$
A few things to note here. Since I added example output to the above steps, you may wonder why there is a blank prompt after the "cd" and the "cat" steps. This is normal Unix behavior. Many times, commands will not print out anything if they operated correctly. So, since I was able to change directories correctly in the first step, I got no output. In the second step, I'm asking the system to print information about the file ("ls" means "list", think "dir" in Windows), so that's why we see output. In the third step, I'm asking the system to read the file ("cat" means "concatenate"), but to redirect the output to the system bit-bucket (/dev/null). Don't worry too much about what /dev/null is -- think of it as a black hole. Anyway, since all the output is going there, that's why we don't see any output there either.
Why do I want to do this? Well, since "cat" will read the file without caring about what application created it, it's a good way to test the file's integrity in the filesystem itself. If there is something wrong with this file, the "cat" will get throw an error.
One last thing to mention, and hopefully this won't confuse the matter. If you have a file that doesn't have spaces in its name, please use that one to test with. That's why I used SmithDoc.txt. The command line can certainly interpret files with spaces in the name, but you must enclose the filename in quotation marks, or escape the space (don't worry about what that means). So, if my filename was actually Smith Doc.txt, anytime I typed this on the command line, I'd have to do:
prompt$ ls -l "Smith Doc.txt"
and
prompt$ cat "Smith Doc.txt" > /dev/null
Hopefully this all makes sense!