root can't vi or more on a file

[Hanry Zhou]

I got permission denied message

here is the infor on this file, xyz

lrwxrwxrwx 1 root root .... xyz

any idea?

Thanks,

[Jeff Schussele]

Hi Hanry,

That file is a symbolic link. You need to edit the file it points to.
BUT it still should have let you edit it IF you're root.

I suspect that the file it linked to is now gone. Check to see if the link destination still exists.

Rgds,
Jeff

[Sridhar Bhaskarla]

Hi,

Is this link pointing to a NFS mount which is not exported with correction options?.

-Sri

[Helen French]

As Jeff mentioned, I think the actual file is not present now. Check if it's available now and if yes, the permission of that file. The one which you posted is a link file.

[Hanry Zhou]

how to find out where/what is the destination file?

it doesn't look like a soft link.

[Sridhar Bhaskarla]

Hi,

If the destination files doesn't exist, it will create one.

Looking at the information given by you, a hardlink will have the count 2. Yours is a symbolic link created with ln -s. It should have been something like this

lrwxr-xr-x 1 root sys 5 Feb 11 15:22 file2 -> file1

The file next to -> is the destination. Can you post the entire string (ll file)?

-Sri

[Hanry Zhou]

the entire strings is almost posted already, except the data and time, but i put it again.
lrwxrwxrwx 1 root root 20 Feb 11 15:45 xyz

If it was soft link, would I get permission denied, if the destination is gone?

[Hanry Zhou]

I just did a test:

if I remove the destination file, the symblyc link should be still shown, and you will get the message of "no such file or directory".

But, in this case, I got "permission denied", and there is no link shown here.

[Jeff Schussele]

Well if you do something like

ln -s " " foo

you still get

lrwxrwxr-x 1 root sys 1 Feb 11 15:38 foo ->

Nothing being pointed to, BUT you still get the arrow.
So this is weird.

My 2 cents,
Jeff

[Sridhar Bhaskarla]

Well - this is weird. A last thing you can do before I suggest that you can remove this by simply doing a 'rm xyz' is do an

#ll > ll.out
#cat -v ll.out

and watch for any misterious characters corresponding to this link.

-Sri

[Chris Watkins_1]

This *is* a weird one, for sure.
What do the following commands show?

#file xyz
#getacl xyz

[Hanry Zhou]

file xyz
sytems: cannot open
getacl systems
sh: getacl: not found

[Jeff Schussele]

Well it gets even more interesting.
In my above example of linking to "nothing" a file foo gives cannot open.
BUT a what foo gives
can't open foo (26)
And according to errno.h 26 is ETXTBSY Text file busy....hmmmm....

Jeff

[Chris Watkins_1]

What version of the OS are you running?
If you have getacl... it's /usr/bin/getacl. Sorry.

[Jeff Schussele]

I'm wondering if that file's linked to std/out/in/err, pipe, socket or something.

My 2 cents,
Jeff

[Hanry Zhou]

it's 11.0

how do i find if the file is/was pointing to pipe, socket,...

Can we conclude that the file has been corrupted? therefore I can just try to remove it since there is no way to recover it.

[Sridhar Bhaskarla]

Hi,

Use 'cat -v' to see if any of the special characters associated with it.

#ll > ll.out
#cat -v ll.out

-Sri

[Hanry Zhou]

Sri,

I did that.

The name of the file should be correct, and should not have any control characters in it, otherwise, I will get the message like "the file is not found".

[Clay Jordan]

!!! SEE SEVERE WARNING BELOW !!!

This may not be the best idea but assuming the file system is vxfs, I did find that you can do an `ls -i` to get the inode and run:

`echo "DDDi;+80B;p 96 c" | fsdb -F vxfs `, where DDD is the inode number. For any link originally 96 characters or less, you should see it in the output.

!!! SEVERE WARNING !!! - per the HP manpage, [ failure to use fsdb correctly ] can lead to complete destruction of the file system and total loss of data.

... but that aside, the command above is not changing anything, merely going to the inode, seeking 80 bytes ahead, and then printing the following 96 bytes.

[Jeff Schussele]

Wow Clay - there's a guy that's loves to live on the edge.
But seriously - he has a valid point - hunting this dog down's looking like fsdb is the a viable tool for the job.
But it also looks like rm is the *proper* tool for the job, huh Hanry.
I gotta admit I love the hunt more than most, but it sounds to me like there's not many options Hanry.

My $0.02,
Jeff

[Jeroen Peereboom]

L.S.

What about an fsck? Everyone agrees it's a strange phenomenon, so better try and repair it.

JP.

[Elmar P. Kolkman]

You could do: ls -lL xyz | cat -t
This would walk the symbolic link (if it is a symlink) and show the real filename. Since something strange is happening with the result of the ls output, you should pipe it through the cat -t (-t will output tab characters as ^I).