On Fri, 4 Dec 2020 09:25:07 -0800, Charles Mills wrote:
>@Gil, weren't you going to try a mkdir wombat/cd wombat endless loop and see
>where it failed?
>
My latest attempt:
# ###############################
#! /bin/sh
# Doc: Test limits of path length (PATH_MAX)
# and directory nesting depth.
Build() { F="$1"
( while mkdir "$F" && cd "$F"; do pwd; done ) | tee "$F.log"; }
set x "Ridiculously long file name"
for I; do
Build "$I"; done
echo; uname -sr
for I; do
wc "$I.log"
tail -1 "$I.log" | wc; done
exit
# ###############################
I've long feared to try such things on z/OS because it's too easy to
create an object on which "rm -r" fails because of either excessive
recursion depth or excessive geenerated path length.
I'm not afflicted with a DOS system to test.
On Linux, it "fails cleanly":
Linux 4.19.0-12-amd64
2041 2041 4196296 x.log
1 1 4096
145 31900 298410 Ridiculously long file name.log
1 436 4074
The limitation seems to be path length (~4096) rather than
nesting depth (at least 2041).
On MacOS it generates a stream of error messages until I interrupt it:
chdir: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
pwd: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
But never sets error status. I suspect that setting the environment
variable PWD may mask an underlying problem.
>What happens if you make ~the maximum length path (~1024?) and then mount it
>on some mount point?
>
>It seems like any "opt-in" for a longer path name would want to be program by
>program (again, analogous to long parms)
>
YA program object attribute? Or JCL JOB option
I feel the same way about REFRPROT. A site might need to keep
REFRPROT(NO) for backward compatibility while conscientious
programmers should enable REFRPROT(YES) for their own programs.
(REUS(REFR,REALLY)?)
>because I as a vendor would have no control over whether a customer did a
>"global" opt-in in PARMLIB. (I would just get the "it blew up" ticket.)
>-----Original Message-----
> ...
>On Fri, 4 Dec 2020 08:19:34 -0500, Peter Relson wrote:
>><snip>
>>And that's why z/OS will never change the maximum path length by default
>>(I actually thought it was 1024, but my knowledge is only from what
>>CSVQUERY implemented and documents for returning the path name). There
>>would have to be some sort of "opt-in" for a longer name.
>>
z/OS seems to be inviting the pitfall by not providing the POSIX-required and
safe "allocating" form of realpath()?
>
A programmer with FOSS code that compiles successfully on a POSIX-conformant
system and fails on z/os because of the lack of PATH_MAX and who is most
familiar with: Authorized Assembler Services Guide
DALPATH specifies the pathname of the z/OS UNIX file to be allocated.
... The maximum length of the pathname is 255 characters
and: z/OS: MVS JCL Reference; DD: PATH
pathname ...
• Has a length of 1 through 254 characters, not including the slash.
... is apt to take 255 as gospel and code in desperation:
#ifndef PATH_MAX
#define PATH_MAX 255
#endif
(Why is the DALPATH parameter limited to 255 bytes, given that the
length is passed in a halfword?)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
