Hi.
I was moving a mp4 file from partition1 to the partition2, I leave the machine and when I returned the computer was turn-off. I don't know why.
I start again the PC and when I try to open partition2 the windows folder is empty with a message told me:

Error when getting information for a file "/media/partition2/namefile.mp4" input/output error.

I try to delete that "namefile.mp4" but was impossible, from a terminal command line not worked also from Midnight Commander not worked, even attempted from a LiveCD but with the same result. I have a lot of data in that partition. Is will be possible recover the partition or delete that particular file without lose all content of partition?

I discover it this:
When I open the partition2 whit File Manager (Thunar) in the Dir-bar I type a direction of a SubFolder (example: /media/partition2/VideoMusic) and I can read and play the files in that folder, only "/media/partition2" in not readable.
Well, apparently the problem is the file namefile.mp4 in the main directory of the partition2.

Thanks in advance.

I have had similar problems when power is lost while writing a large file. Some data is written wrong and may wipe out everything, or it may be confined to the single file.

I would, BEFORE writing anything else to that drive, do a backup of everything that can still be accessed. Once that is done, reformat the filesystem then restore what was removed.

...or run an fsck on the unmounted partition, then try to delete the file as root.
of course a backup is always a good idea.

<b>computersavvy:</b>
Apparently the problem is only in the file because from a terminal or using the prog. Midnight-Commander I can access the other .mp4 files in the main directory (partition2). No proble to play the files with VLC.
When I try to rename, delete or move that file I get the same error message. Thank you for your reply.

<b>ondoho:</b>
I already tried to delete it or move it as root but I did not try to run fsck, I will try and then tell you if it worked. Thank you for your answer.

IIRC fsck does not repair by default.
Read its man page.
If you repair, make a backup of the raw partition data first.
Save all output to show it to us.

A backup is complicated due to the number of long files.
I will continue testing with fsck, so far I have not been successful.

Nothing happened with fsck.
Now I am thinking, partition 2 is storage only.
I know it still has an NTFS file system but it is not the partition the operating system is on.
fsck is useful in this case?

Why not?
Storage only filesystems also need to function properly.
Read the fabulous manual:

Actually it depends. In this case fsck uses ntfsfix which can only repair minor problems. Since the partition is mountable and you only have trouble with a single file probably not but I've never encountered this problem. The only way the it might be fixed is if you can run chkdsk from a Windows system.

I would not use fsck on an ntfs partition. If the windows system can access that partition I would recommend the native chkdisk instead.

AFAIK Linux access to ntfs filesystems is still 100% reverse engineered and may not be 100% the same as the native tools.

No way Jose.
I tried everything I know and I always get the same error. The "problem file" has a number in parentheses in his name and
when I try to delete, rename or move it shows me this error:
Bash: Syntax error near unexpected token `(`

To make a chkdisk I have to move the HD to a computer with VirtualMachine and install some Windows.
Thanks to all for a help.

You haven't specified the name of the file you're trying to move/delete but the parentheses are confusing bash as it attempts to parse your command line.

Try enclosing the troublesome file name inside single quotes to keep bash from interpreting whatever that character is, say:
You could also try escaping that open parenthesis character -- using: \( -- but that may not be the only character that bash will wind up (mis)interpreting as having a special significance. You might need to escape additional characters. I find that enclosing the mess in single quotes works the vast majority of the time.

HTH...