RE: includes inside squid.conf

On 1 Apr 2002, at 8:06, Alex Rousskov <rousskov@measurement-factory.com> wrote:

> On Mon, 1 Apr 2002, Andres Kroonmaa wrote:
>
> > When I wrote it, I thought that people would start using symbolic
> > links left and right, so there is a need to identify unique files,
> > not links. Inodes provide this. They make it possible to trap
> > exact file that is creating a loop even if many links point to it.
> > I wanted to detect exact moment when loop is created.
>
> I do not see why links present any exceptional situation. I trace of
> current nested #include statements would be sufficient to detect and
> analyse an #include loop. Many compilers, including GCC, use this
> approach to dump a series of "foo included from bar" errors, with
> exact locations for each #include statement. That's all I need to
> break a loop.

 On unix, without understanding of inodes, there is no way to
 distinguish between files. There might be symbolic link, or hardlink,
 or symbolic link of a directory, or mountpoint, or etc... To expand
 given filename into its absolute path, you'd need to traverse the
 directory structure with understanding of underlying OS. I just didn't
 like that path. The alternative would be to _ignore_ possibility that
 different names point to same files, let it include few files multiple
 times and raise error only when exact same name is seen twice. Then
 we simply compare strings as they are provided. We can do that.
 Given that inodes are not portable, we might have to. Initially, I
 just thought this may be unwanted to let some redundant inclusions
 to happen and tried to detect that, and made a "shortcut".
 We can drop that of course, no prob.

> Moreover, one can argue that the above trace is much more clear to an
> average person than an inode-based trace. The loop is visible in both
> traces, but I do not need to know about links to solve the problem.
>
> The inode-based trace requires me to understand that some file is,
> technically, some other file; that extra understanding is not really
> needed to solve the problem in a general case.

 No-no, why? You never tell user about inode, you just tell him that
 this filename has already been included once. Thats it. When bailing
 out, you can show every file being currently open while exiting
 recursion. Inodes just simplifies it for a coder, skipping the need
 to expand any filename into absolute path. Thats left to the OS.
 How would you do that yourself, portably?

 If user has ability to create multiple links to the same file, then
 he already must understand the matter.

> > Besides
> > inodes are alot easier to "remember" and compare ;). For names,
> > you'd need to deal with typical cases like "../squid/etc/file.cfg"
> > and later "etc/file.cfg". Comparing these equal is alot of bother.
>
> Not really. To actually include a file, preprocessor needs an absolute
> filename. Comparing absolute filenames is simply comparing strings.

 Why does it need absolute filename? It is imho very happy with relative
 naming, and usually thats all it cares about. There is very little
 room left for user error.

> Besides, I bet that not every OS has a notion of inodes and that some
> inode declarations are not very portable.

 Thats true.

> > Probably it would be initially simpler to just count recursion
> > depth and limit it to something as Henrik suggested. It would
> > only provide very little help when nonobvious loop is created,
> > we can't pinpoint the faulty #include, but this might be a
> > nonissue. Probably portability outweights that too.
>
> I think detecting a loop is useful and is better than arbitrary (and
> not technically necessary) depth limits alone. I only argue that
> universal and stupid filename-based detection is better than custom
> and smart inode-based detection.

 Better? I doubt. More portable, perhaps.
 But ok, due to understandable resistence to inodes, lets first make
 simple string compare with limited depth safeguard, later we'll see.

> We can have [very large by default] depth limits and loop detection at
> the same time, of course.
>
> > Also, another issue arrives when adding notion of #includes: what
> > is a correct action when #include file is not accessible? Some
> > includes are critical for correct operation, some are not, should
> > we bail out or continue? Perhaps create #include and #required?
> > I tend to wish that we could ignore #include errors, this would
> > make it possible to include configs from files on swap disks if
> > they are mounted, thinking of hotswap disks or netmounts.
>
> IMO, a failed #include operation must be a fatal error. If somebody
> wants to make it non-fatal, they can pre-generate configuration files
> using their custom program.

 If your opinion comes from wish to keep it similar to C processing,
 then I agree. But it would be really lovely to be able to keep all
 swap disk related config on that disk itself and include it as
 optional when found suitable. I for one would like that squid comes
 up after a nasty crash and disk needing manual recovery instead of
 bailing out on either nonexisting swap dir or related include config.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Mon Apr 01 2002 - 10:50:38 MST