The first line is the 16 byte directory entry as decimal numbers, the second line is 16 bytes as characters.
The first two bytes are the inode number - so you read that from the first decimal number of the first line, the second line is used to see the file name. Since the first two bytes are the inode number (as chars) you ignore them.
0000300    04256   28774   26988   25856   00000   00000   00000   00000
         020   �   p   f   i   l   e  \0  \0  \0  \0  \0  \0  \0  \0  \0
from this pair of lines: the file "pfile" has inode number 4256.

ls -i pfile should confirm this.

What I would have wanted to see from fsck was which inode showed up as duplicate, and use ncheck to find all files referencing the inode.

Hi
od -dc output intresting:
(For example unicode or unknown character on second line between 020 and pfile )
0000300    04256   28774   26988   25856   00000   00000   00000   00000
         020   �   p   f   i   l   e  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000320    04186   29539   29289   28788   29440   00000   00000   00000
         020   Z   s   c   r   i   p   t   s  \0  \0  \0  \0  \0  \0  \0
0000340    04288   30052   30061   28672   00000   00000   00000   00000
         020   �   u   d   u   m   p  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000360    04320   28261   29815   28530   27392   00000   00000   00000
         020   �   n   e   t   w   o   r   k  \0  \0  \0  \0  \0  \0  \0
How can I solve this problem online?
Thanks!
Toth

Yes fsck will be able to fix actual filesystem problems,
if there are indeed any when you run it.

To unmount the filesystem you have to stop all the processes using it.
Therefore you may as well shutdown to single user mode,
stop all applications anyway, and try the "ipcs" "ipcrm" "rm -i" suggestions first, because they have almost the same requirements.

Running ipcrm on the wrong message queue for a running application could be nasty.  However, something has gone wrong with the application clearly, and so you might need to re-start it in any case to recover fully from this.
Maybe ipcs shows that there is no longer a message queue being held open by anything for this file, just an old filename reference in the directory file.

The "rm -i" of an apparently non-existent file shouldn't be doing any more than removing the name from the containing directory file list, and you can do that with the system up.  fsck would also fix that type of issue, but only with the filesystem unmounted.

OK, so lots of files were listed and then the one name "does not exist", even though it apparently knows enough about it to mention that.

The directory (which is a file) contains the list of file names in that directory. 

The "./*" in your commands is being expanded by the shell to the names of all the files in the directory and then the command is run with all those expanded names sent to it. 

There could for example be something odd with that file name, a hidden character perhaps.  The graphic space character in the character set (which can be called up in an octal way at least) can be used to create a file with a name of apparently <blank> which then doesn't show up in a normally viewed "ls" list say. 

But the other message about a "message queue" is significant also.  Research the commands "ipcs" and "ipcrm":
man ipcs
man ipcrm

As the message queue area is probably the reason, try that first.  The only message queue I have on my system is for "printq".  I suggest you shutdown to single user operations - to be safe there is nothing else running that might need such a thing - then list the message queues the system thinks it has with "ipcs" and try "ipcrm -q XXXX" to delete whatever XXXX you think it might be associated with this file.  (A reboot would surely fix any erroneous deletions at this point.)

Then if it's still a problem with "ls" and "du", try an "rm -i *", which will present each of the expanded filenames for possible removal if you enter "y" to confirm it, and that does then handle each odd name too. 
Alternatively, try making a new directory, copying all the known OK files in to that with "cp -p name1 name2 etc ../newdirectory" to maintain settings, then delete the original directory from above it (so that the offending name doesn't enter into the piece).

Note by the way that fsck only works properly on an unmounted filesystem, as where mounted you will get "errors" about open files and invalid inode maps with random frequency because the filesystem is then in use.  So that output was actually OK, nothing really wrong with your filesystem at all in all probably.