On Thu, 2 Nov 2017 08:14:42 +0100, Peter Hunkeler wrote:
>
>And this makes it ever worse to scan such trees. You need to find a way to
>learn what directories are to be searched, and then start another search for
>each one of them.
>
I wrote a script to scan the mount maps (not fetch-protected) and mount (with
"ls -d")
everything it found. I used it to check for malfunctioning filesystems.
Admins never
complained; I was discreet and doubt that they noticed; I did report problems I
found.
Couldn't expad wildcards.
>Think about that this means to the file level backup process, should you have
>one. That process will again see only what is munted at the time the backup
>runs.
>
It could start with the mount maps. But the wildcard limitation remains.
On Wed, 1 Nov 2017 14:12:41 -0700, Lizette Koehler wrote:
>See how well I understand Unix? ;-O
>
That being the case, I'll offer another suggestion.
>Yes - what you wrote - I have a directory with a huge bunch of directories
>under it
>
"find" can accept multiple starting points. E.g.:
find /etc /bin /u/* -name '*.new'
(but z/OS recognizes only mounted filesystems when expanding wildcards.
Solaris, in contrast, (partly) follows the mount maps.)
>> Probably a silly question, but are you really searching from the root, or
>> doing something like:
>>
>> find /The/Actual/Parent/Dir/I/Am/Looking/At/ -name '*.new'
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
