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