cannot delete recursive directory

[Carme Torca]

Hi,

I have one directory with a lot of recursive directories...
core/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/..../core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237

I have prove to remove with the inum
find . -inum 1233 -exec rm -r {}\;
, but it does not work. I have prove to remove with rm -r
rm -r core
, but it does not works ok. The two commands saids: "pwd: File name too long"

Could anyone help me?

Thanks,
Carmen.

[Rasheed Tamton]

Hi,

find . -inum 1233 -exec rm -r {} \;

But before you use rm, try listing the files by ll and once you are confirmed that the files are ok to be deleted, then use.

Your issue was that you omitted a space in between the {} and \

Rgds.
Rasheed Tamton.

[Robert-Jan Goossens]

Hi Carmen,

Try

Inodes are only unique to one filesystem!

# find /your_filesystem -inum 1233 | xargs rm

Regards,
Robert-Jan

[Carme Torca]

Hi,

Its not possible.

find . -inum 1233 |xargs rm -r

cannot open ./core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/core_16237/: No such file or directory
pwd: Too many open files

[Dennis Handly]

>Robert-Jan: # find /your_filesystem -inum 1233 | xargs rm

When doing -inum there will only be the one file/directory, so why use xargs?

An if you want performance with find you should use a "+":
find . -inum 1233 -exec rm -r {} +

[Robert-Jan Goossens]

Hi Carmen.

--
Too many open files
--
You running into a kernel parameter limit or a ulimit problem, could post the the output of "ulimit -a" and your current kernel parameters settings for below parameters.

maxfiles
maxfiles_lim

Regards,
Robert-Jan

[Robert-Jan Goossens]

Dennis, the inode can still be a directory with to many files for the shell to remove (exceeding the command line's maximum length), using xargs or find ... + will bypass the shell limits.

Im not going to argue all remarks you make in the threads, because I feel this is not the intent of this forum.

Regards,
Robert-Jan

[Dennis Handly]

>cannot open ./core_16237/core_16237/...
pwd: Too many open files

The last time this happened to me, I had to descend into the directory tree way down then remove the files from a subtree using "rm -rf .".
Once this is done, you can restart at the top.

>Robert-Jan: the inode can still be a directory with too many files for the shell to remove (exceeding the command line's maximum length)

That can't happen, the shell isn't involved, only rm(1). The result of "find . -inum" is likely to be just one file. So you are executing:
rm -r long-directory-path

This should fit in the shell's command line.
Note: "rm -r" doesn't recursively fork/exec itself to remove the files. The recursion is within the process. Obviously rm(1) can't handle this tree as is but neither would using xargs(1) and then rm(1).

>using xargs or find ... + will bypass the shell limits.

Naturally but this trick isn't needed when using "-inum".

[Carme Torca]

Hi,

I have increase it,

# ulimit -a
nofiles(descriptors) 64
to
nofiles(descriptors) 8192

but it aborts again.

[Carme Torca]

Sorry....I forget one this!! this directory its on /disc/lost+found/ core_16237/....

its anyone to eliminate de lost+found and recreate again??

Thanks!
Carmen.

[Rasheed Tamton]

Can you post the output:

ncheck -F vxfs /dev/vg??/rlvol?|grep 1233
ll -i /dir |grep 1233

[Carme Torca]

Here you are,

Thanks,

1233 /lost+found/#1233/.
478465 /lost+found/#1233/core_16237/core_16237/core_16237/.
227910 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/core_162 37/core_16237/core_16237/core_16237/core_16237/core_16237/.
358858 .../#1233/core_16237/core_16237/core_16237/core_16237/core_16237/core_ 16237/core_16237/core_16237/core_16237/core_16237/core_16237/.
626633 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/.
677899 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/core_162 37/.
717773 /lost+found/#1233/core_16237/.
717774 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/core_162 37/core_16237/.
68427 /lost+found/#1233/core_16237/core_16237/.
751944 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/core_162 37/core_16237/core_16237/.
797513 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/core_162 37/core_16237/core_16237/core_16237/.
68428 /lost+found/#1233/core_16237/core_16237/core_16237/core_16237/core_162 37/core_16237/core_16237/core_16237/core_16237/.


$ls -i /disc/lost+found |grep 1233
1233 #1233

[Dennis Handly]

Have you tried:
cd /lost+found/#1233/core_16237
cd core_16237/core_16237/core_16237/core_16237
rm -rf .

If the rm fails, repeat the cd to go deeper, then repeat.

[James R. Ferguson]

Hi Carmen:

> its anyone to eliminate the lost+found and recreate again??

In the case you describe, you aren't going to be able to remove from this level if you can't remove from a subordinate directory.

That said, for your information, yes. You can recreate the 'lost+found' directory in a filesystem with 'mklost+found'. See the manpages for more information.

Regards!

...JRF...

[Peter Nikitka]

Hi,

@Dennis: you can't remove the tree you're sitting on (rm -rf .):
>>>
cd /lost+found/#1233/core_16237
cd core_16237/core_16237/core_16237/core_16237
rm -rf .
<<<
Try instead

cd /lost+found/#1233/core_16237
cd core_16237/core_16237/core_16237/core_16237
rm -rf core_16237

mfG Peter

[Dennis Handly]

>Here you are,
1233 /lost+found/#1233/.
478465 /lost+found/#1233/core_16237/core_16237/core_16237/.

It doesn't look like there is a cycle in the directories. It looks like my previous case of some script gone awry.

>Peter: @Dennis: you can't remove the tree you're sitting on (rm -rf .):

Oops, I thought rm(1) would at least try to get the others.

>rm -rf core_16237

Yes or "*" if there is only the one directory there.

Also, if the tree is really deep, you can cd 10s of directories at a time:
DD=core_16237/core_16237/core_16237/core_16237/core_16237
DD20=$DD/$DD/$DD/$DD
cd $DD20