Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Deleting a recursive hard link
- Thread starter bombcan
- Start date
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
If it's linking to a directory, it can't be a hard link.
What does "ls -al /usr1/log/.KSQmEa" output?
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
A Simple Code for Posting on the Web
What does "ls -al /usr1/log/.KSQmEa" output?
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
A Simple Code for Posting on the Web
- Thread starter
- #5
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
Okay, what's this show?
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
A Simple Code for Posting on the Web
Code:
ls -idl /usr1 /usr1/log/.KSQmEa- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
A Simple Code for Posting on the Web
- Thread starter
- #7
- Thread starter
- #9
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
Wow. That's one broken filesystem. Sorry to disappoint, but a CATE doesn't give me any magical insight into the manner in which it's broken, or if this symptom is the only damage.
If /usr1 is a filesystem, unmount it and see if fsck can fix it.
If not, or if fsck can't fix it, you can try the following at your own risk:
back up /usr1
back up /usr1 again
pull tables of contents off of both backups to verify
cross fingers
[tt]unlink /usr1/log/.KSQmEa[/tt]
Typing with crossed fingers is the most difficult part.
Per documentation, that should do it (but per documentation the problem shouldn't exist in the first place). Sorry I can't give you a more solid answer.
Let us know how it goes.
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
A Simple Code for Posting on the Web
If /usr1 is a filesystem, unmount it and see if fsck can fix it.
If not, or if fsck can't fix it, you can try the following at your own risk:
back up /usr1
back up /usr1 again
pull tables of contents off of both backups to verify
cross fingers
[tt]unlink /usr1/log/.KSQmEa[/tt]
Typing with crossed fingers is the most difficult part.
Per documentation, that should do it (but per documentation the problem shouldn't exist in the first place). Sorry I can't give you a more solid answer.
Let us know how it goes.
- Rod
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
A Simple Code for Posting on the Web
The problem he's going to have running a simple backup is when it walks the filesystem to build a file & directory list - any backup software is going to process that hardlink as a normal directory and go into a perpetual loop. That should be true for both inode and filename type backups.
Here's the way I would deal with it, assuming there is sufficient disk space to equal to a full copy of the filesystem.
First, build a list of all files in the filesystem, excluding the offending directory.
not 100% tested since I can't replicate the fault, but should suffice as pseudocode:
At this point, you can go a couple of different ways.
1) if you have enough space for 2 copies of /usr1:
a) Create a tarball using -L and the filelist that you just created to create a backup of /usr1 that excludes the problem directory.
b) Remount the broken filesystem as /usr1broken
c) Create a new /usr1
d) untar the tarball
2) if you have enough space for only 1 copy of /usr1
a) Create a second filesystem /usr1copy, and iterate through that filelist copying each file, maintaining permissions.
b) Remount the broken filesystem as /usr1broken
c) Remount the copied filesystem as /usr1
d) Repair any missing permissions (theoretically parse the entire file *and* directory tree, then pull the owner/group/perms for the same file from the original)
Both of these methods are intended simply to keep the broken filesystem around untouched, so there is always a recovery point if something goes badly wrong.
A third method would be to make a copy of the broken LV, perform a splitlvcopy on it, then perform the unlink as Rod mentioned. I don't favor doing this as if you've got a filesystem with a seriously weird problem (as you do), I would be concerned that it could have other problems. Copying the data to a newly created filesystem should ensure that you have a filesystem structure without hidden problems.
Here's the way I would deal with it, assuming there is sufficient disk space to equal to a full copy of the filesystem.
First, build a list of all files in the filesystem, excluding the offending directory.
not 100% tested since I can't replicate the fault, but should suffice as pseudocode:
Code:
#!/bin/ksh
FILELIST=/a/directory/and/a/file
rm ${FILELIST} 2>/dev/null
# first process the top level of the /usr1 directory, excluding the logs subdir
cd /usr1
ls | grep -v "^log$" while read FDNAME
do
find /usr1/${FDNAME} -type f >> ${FILELIST}
done
# second process the log directory, skipping the offending directory
cd /usr1/log
ls | grep -v "^\.KSQmEa$" | while read FDNAME
do
find /usr1/log/${FDNAME} -type f >> ${FILELIST}
doneAt this point, you can go a couple of different ways.
1) if you have enough space for 2 copies of /usr1:
a) Create a tarball using -L and the filelist that you just created to create a backup of /usr1 that excludes the problem directory.
b) Remount the broken filesystem as /usr1broken
c) Create a new /usr1
d) untar the tarball
2) if you have enough space for only 1 copy of /usr1
a) Create a second filesystem /usr1copy, and iterate through that filelist copying each file, maintaining permissions.
b) Remount the broken filesystem as /usr1broken
c) Remount the copied filesystem as /usr1
d) Repair any missing permissions (theoretically parse the entire file *and* directory tree, then pull the owner/group/perms for the same file from the original)
Both of these methods are intended simply to keep the broken filesystem around untouched, so there is always a recovery point if something goes badly wrong.
A third method would be to make a copy of the broken LV, perform a splitlvcopy on it, then perform the unlink as Rod mentioned. I don't favor doing this as if you've got a filesystem with a seriously weird problem (as you do), I would be concerned that it could have other problems. Copying the data to a newly created filesystem should ensure that you have a filesystem structure without hidden problems.
What if you do this
cd /usr1/log
ls -a | grep "^\."
Apart from the .KSQmEa entry do you see both . and .. ?
If you just have the . and .KSQmEa, then it is possible that the .. entry was somehow renamed. Not sure if that can be renamed to .. again. I'd go with the backup and restore strategy.
If you have . , .. and .KSQmEa, then backup, backup and try the unlink. But if this is the case, I'd also look for more of the same at least:
find /usr1 -type d ! -name ".KSQmEa" -ls
Of course this will go into a recursive pathname explosion if it finds any other offending dir hardlink, but then just ctrl-C the find command and run it again, including another '! -name "Whatever"' until you have found all the problem hardlinks...
As to the origin of this problem, I'm guessing a leftover NFS deleted file - I've seen filenames like that on NFS server filesystems when NFS client doesn't clean up like it should or after broken NFS links... Just a hunch.
And yes Rod, you are right: a CATE doesn't provide any magic spells for this one, not even for a wizard... ;-)
HTH,
p5wizard
cd /usr1/log
ls -a | grep "^\."
Apart from the .KSQmEa entry do you see both . and .. ?
If you just have the . and .KSQmEa, then it is possible that the .. entry was somehow renamed. Not sure if that can be renamed to .. again. I'd go with the backup and restore strategy.
If you have . , .. and .KSQmEa, then backup, backup and try the unlink. But if this is the case, I'd also look for more of the same at least:
find /usr1 -type d ! -name ".KSQmEa" -ls
Of course this will go into a recursive pathname explosion if it finds any other offending dir hardlink, but then just ctrl-C the find command and run it again, including another '! -name "Whatever"' until you have found all the problem hardlinks...
As to the origin of this problem, I'm guessing a leftover NFS deleted file - I've seen filenames like that on NFS server filesystems when NFS client doesn't clean up like it should or after broken NFS links... Just a hunch.
And yes Rod, you are right: a CATE doesn't provide any magic spells for this one, not even for a wizard... ;-)
HTH,
p5wizard
- Thread starter
- #14
lol. I looked at the manpages for link and unlink. Those commands look like very good ways to seriously screw up a filesystem, so I was going to leave those to people who know them better than I do.
+1 to p5wizard's suggestion for checking for other brokenness before running a backup.
+1 to p5wizard's suggestion for checking for other brokenness before running a backup.
- Status
Similar threads
- Question