I also was not able to view (some) of my attached files.  I narrowed it down to those that I had attached from a local drive.  Those on a network drive were fine.

So, I figured that I could "fix" this situation by preventing users from attaching local files through the use of a validation rule.  Here is the formula for the validation rule that I wrote:

OR ( CONTAINS( File_Path__c , "C:"), CONTAINS( File_Path__c , "D:"))

Once this validation rule was in place, I was prevented from attaching a locally stored file.  This was good.  However, the error message that was displayed only said "The file is not successfully attached".  It did not explain WHY it was unsuccessful.  I had included that information when I wrote my validation rule, but it wasn't displayed from the page where the attachment is done, since it is not a standard edit page.

I'm not a Developer, so I thought I probably went as far as I could, but decided to look into the scontrol anyway to see how complex it might be to "fix" this issue.  I was pleased to find that I was able to come up with a fix.  There's an alert line which displays the error, and I simply modified it to be more descriptive.  The new alert line states:

alert("The file is not successfully attached. Make sure that you selected a file stored on a NETWORK drive. You can not attach files that are stored on your C: or D: drives");

There's other potential issues I can see our users encountering if they don't all have the same mapping to the network drive, or if they attempt to attach files from local drives with letters other than C or D, but I feel that I have at least resolved the problem that I had during my testing.  Perhaps this is also the cause of you not being able to view your attached files.