Messages in this thread | | | Date | Wed, 10 Dec 1997 17:17:10 +0100 (MET) | From | (Guest section DW) | Subject | Re: "while :; do mkdir;cd mkdir;done" |
| |
: From arcangeli@mbox.queen.it Wed Dec 10 16:38:04 1997
: On Wed, 10 Dec 1997, Guest section DW wrote:
: >: From: Andrea Arcangeli <arcangeli@mbox.queen.it> : > : >: #!/bin/sh : >: while :; do mkdir foo; cd foo; done : > : >: create a full pathname that exceed a page memory (do_getname() return : >: -ENAMETOOLONG), so can' t be referenced in any way and so can' t be : >: deleted from rm -r etc... : > : >: PS. How can force the deleting of a tree created without the patch? : > : > An old and well-known problem. : > The tree can be deleted by deltree (ftp.win.tue.nl:/pub/linux/misc). : > Maybe recent GNU versions of rm will do as well.
: So a kernel patch is uneeded?
I have not seen this (your?) patch, only pointed out that there is a program to remove deep trees.
Pathnames can be arbitrarily long, but there is a limit to the size of pathnames that the kernel will handle. This is how it always has been. Nothing wrong here. No patch needed.
: So why James Mastros had a filesystem panic : after running the offending script?
How should I know? You want to cure symptoms instead of bugs? If it is reproducible, someone should investigate this panic, and fix whatever is wrong. Having long names is not wrong.
: And how can be useful a tree that can't be reached in any way?
It can be reached.
: At least for my own system I like my patch to be allowed to run the script : and delete the PAGE_SIZE long tree with rm -r. For my system 4096 : character of path are well.
Ah, so it is your patch, and I understand that you want to limit the maximum length of pathnames. That might well be a violation of POSIX. Anyway, there is no good reason to impose such a restriction. But on your own machine you can, of course. I think the latest development version of rm is able to remove very deep trees, so this deltree utility will soon be obsolete.
| |