Unix questions - while true; do mkdir -p neener; cd neener; done

Author

while true; do mkdir -p neener; cd neener; done

KKramsch

2004-11-28, 2:47 am

I've seen this sort of one-liner described as a "Unix prank":

bash% while true; do mkdir -p neener; cd neener; done

I can see how this would create a very large number of directories,
and a very deep path. I can also imagine that executing this
one-liner could cause serious problems to the OS, but don't know
enough about the internals of Unix to predict exactly how the system
would react to such code. Exactly what would happen? Would Unix
just abort the script and go on without any problems? Or would the
system become disabled or crippled somehow?

Thanks,

Karl

--
Sent from a spam-bucket account; I check it once in a blue moon. If
you still want to e-mail me, cut out the extension from my address,
and make the obvious substitutions on what's left.

Chuck Dillon

2004-11-29, 7:51 am

KKramsch wrote:
> I've seen this sort of one-liner described as a "Unix prank":
>
> bash% while true; do mkdir -p neener; cd neener; done
>
> I can see how this would create a very large number of directories,
> and a very deep path. I can also imagine that executing this
> one-liner could cause serious problems to the OS, but don't know
> enough about the internals of Unix to predict exactly how the system
> would react to such code. Exactly what would happen? Would Unix
> just abort the script and go on without any problems? Or would the
> system become disabled or crippled somehow?

I would think it would continue until it filled the file system with no
data other than the huge number of dirents. Any recursive attempts to
discover the contents from the top level neener/ would probably fail
with a path too long error or out of memory errors. So it could be
difficult to clean it up without writing a script to do it without
hitting either limit or as a last resort regenerating the file system.

It would only affect the OS if it was done on a file system critical to
operation. If not run as root that should be limited to /tmp or
possibly some log or spool directories.

-- ced

>
> Thanks,
>
> Karl
>

--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.

Stephane CHAZELAS

2004-11-29, 7:51 am

2004-11-29, 08:30(-06), Chuck Dillon:
[...]
> I would think it would continue until it filled the file system with no
> data other than the huge number of dirents. Any recursive attempts to
> discover the contents from the top level neener/ would probably fail
> with a path too long error or out of memory errors. So it could be
> difficult to clean it up without writing a script to do it without
> hitting either limit or as a last resort regenerating the file system.
>
> It would only affect the OS if it was done on a file system critical to
> operation. If not run as root that should be limited to /tmp or
> possibly some log or spool directories.
[...]

The process (shell) current directory would also be unknown
(getcwd returning ENAMETOOLONG)

Some shells would not be able to go into that directory (that's
the case of bash, dash and pdksh at least, and there's a bug
(fixed in next release) with zsh, and there are bugs with ksh93).
because they try to maintain a representation of the full
directory (for the logical cd .. I guess).

rm -rf /top/level/neener

should be OK with a reasonably coded rm, I'd bet (you may get
stack overflows or memory allocation errors though)

--
Stephane

Michael Paoli

2004-11-30, 2:47 am

KKramsch <karlUNDERSCOREkramsch@yahooPERIODcom.invalid> wrote in message news:<cobjd0$hra$1@reader1.panix.com>...
> I've seen this sort of one-liner described as a "Unix prank":
> bash% while true; do mkdir -p neener; cd neener; done
> I can see how this would create a very large number of directories,
> and a very deep path. I can also imagine that executing this
> one-liner could cause serious problems to the OS, but don't know
> enough about the internals of Unix to predict exactly how the system
> would react to such code. Exactly what would happen? Would Unix
> just abort the script and go on without any problems? Or would the
> system become disabled or crippled somehow?

At some point the mkdir or cd in the loop would fail.

The resulting directory structure (and/or its space or inode
consumption) may be problematic and/or may cause other things
to break when encountering it. This might get the systems
administrator(s) very annoyed. Note also that in some cases (with
some combinations of shells and UNIX flavor(s)), removing such a
deep directory structure can be fairly problematic (e.g. rm -rf
may fail to remove it). So, ... don't mess with it unless you
know what you're doing, know you won't cause a problem with it,
and know how you're going to clean it up.

For some reason, at least the particular version of the bash
shell I have doesn't handle this too well. The ash shell
(a Bourne-shell clone) seems to handle it more cleanly.
Nevertheless, still some interesting behaviors are observed.

$ echo $BASH_VERSION ${BASH_VERSINFO[@]}
2.05a.0(1)-release 2 05a 0 1 release i386-pc-linux-gnu
$ mkdir /tmp/neener
$ cd /tmp/neener
$ while :; do { mkdir neener && cd neener; } || break; done
cd: could not get current directory: getcwd: cannot access parent
directories: File name too long
cd: could not get current directory: getcwd: cannot access parent
directories: File name too long
job-working-directory: could not get current directory: getcwd: cannot
access parent directories: File name too long
chdir: could not get current directory: getcwd: cannot access parent
directories: File name too long
.... this error sequence repeats until interrupted ...
$ pwd
pwd: could not get current directory: getcwd: cannot access parent
directories: File name too long
$ mkdir neener
job-working-directory: could not get current directory: getcwd: cannot
access parent directories: File name too long
$ cd neener
chdir: could not get current directory: getcwd: cannot access parent
directories: File name too long
$ pwd -P
$ echo $?
1
$ cd ..
cd: could not get current directory: getcwd: cannot access parent
directories: File name too long
cd: could not get current directory: getcwd: cannot access parent
directories: File name too long
$ cd /tmp/neener
chdir: could not get current directory: getcwd: cannot access parent
directories: File name too long
$ cd /
$ cd /tmp/neener
$ pwd -P
/tmp/neener
$ rm -rf neener; ls -a
.. ..
$ ash
$ while :; do { mkdir neener && cd neener; } || break; done
mkdir: argument list too long
$ pwd -P | wc -c
65329
$ mkdir neener
mkdir: argument list too long
$ mkdir neene
mkdir: argument list too long
$ mkdir neen
mkdir: argument list too long
$ mkdir nee
mkdir: argument list too long
$ mkdir ne
$ cd ne
$ mkdir n
mkdir: argument list too long
$ pwd -P | wc -c
wc: argument list too long
$ pwd -P | dd bs=1 of=/dev/null
dd: argument list too long
$ echo a | wc -l
wc: argument list too long
$ cd ..
$ pwd -P | wc -c
wc: argument list too long
$ pwd -P | dd bs=1 of=/dev/null
dd: argument list too long
$ while :; do cd .. || break; pwd -P | 2>>/dev/null wc -c && break;
done
65322
$ cd /tmp/neener
$ rm -rf neener; ls -a
.. ..
$ pwd -P
/tmp/neener
$

Stephane CHAZELAS

2004-11-30, 2:47 am

2004-11-30, 01:10(-08), Michael Paoli:
[...]
> $ echo $BASH_VERSION ${BASH_VERSINFO[@]}
> 2.05a.0(1)-release 2 05a 0 1 release i386-pc-linux-gnu
> $ mkdir /tmp/neener
> $ cd /tmp/neener
> $ while :; do { mkdir neener && cd neener; } || break; done
> cd: could not get current directory: getcwd: cannot access parent
> directories: File name too long
> cd: could not get current directory: getcwd: cannot access parent
> directories: File name too long

try

cd -P

[...]
> $ pwd
> pwd: could not get current directory: getcwd: cannot access parent
> directories: File name too long

Yes, that's the getconf PATH_MAX limit. getcwd(2) returns
-1 (errno == ENAMETOOLONG)

[...]
> $ while :; do { mkdir neener && cd neener; } || break; done
> mkdir: argument list too long

You must have a variable containing the curr directory (possibly
PWD, PS1 or OLDPWD) in your environment. Those variables should
not be exported.

I think the only filesystem limit is the number of available
inodes (or disk space).

--
Stephane