[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    rm (and others) can't handle paths longer than PATH_MAX
From:       Tavian Barnes <tavianator () tavianator ! com>
Date:       2018-03-13 2:10:39
Message-ID: CABg4E-mzQzVk737Wjk76faXH76TT+bq2agLwxuN60WG230GZ4w () mail ! gmail ! com
[Download RAW message or body]

For example:

$ name="0123456789ABCDEF"
$ name="${name}${name}${name}${name}"
$ name="${name}${name}${name}${name}"
$ name="${name:0:255}"
$ (mkdir deep && cd deep && for i in {1..17}; do mkdir $name && cd $name; done)
$ busybox rm -rf deep
rm: can't stat 'deep/...': Filename too long
rm: can't remove 'deep/...': Directory not empty
...
$ busybox rm -v
BusyBox v1.28.1 (2018-02-19 12:49:35 MSK) multi-call binary.

busybox find deep is similarly broken.  But POSIX says in
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/rm.html:

> The rm utility is required to descend to arbitrary depths so that any file \
> hierarchy may be deleted. This means, for example, that the rm utility cannot run \
> out of file descriptors during its descent (that is, if the number of file \
> descriptors is limited, rm cannot be implemented in the historical fashion where \
> one file descriptor is used per directory level). Also, rm is not permitted to fail \
> because of path length restrictions, unless an operand specified by the user is \
> longer than {PATH_MAX}.

And in http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html:

> The find utility shall be able to descend to arbitrary depths in a file hierarchy \
> and shall not fail due to path length limitations (unless a path operand specified \
> by the application exceeds {PATH_MAX} requirements).

-- 
Tavian Barnes
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]