RE: includes inside squid.conf

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.

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.

> 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.

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

> 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.

Depth limits are a must only if you add #ifdefs or similar
conditionals. Or, generally speaking, when interpreted contents of
"foo.cfg" may change from one access to another. If we allow that, the
maximum depth should be very large by default and should be
configurable.

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.

Same probably goes for #include statements that use URLs rather than
filenames (for people maintaining a distributed hierarchy of caches),
although I do not have a strong opinion here.

Alex.
Received on Mon Apr 01 2002 - 08:06:20 MST