On Mon, 1 Apr 2002, Andres Kroonmaa wrote:
> On unix, without understanding of inodes, there is no way to
> distinguish between files.
A preprocessor job is to open a named file using -Idir directives (or
equivalent) and insert its contents into the current context. A
preprocessor should report I/O errors and, possibly loops. None of
this requires any understanding of inodes or any Unix-specific
knowledge.
> 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.
That path does not exist in a traditional preprocessor. In general,
preprocessors do not know about sym/hardlinks, mountpoints, etc. They
simply append filename to each of the -I directories until they can
open(2) a file.
> 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.
Yes, I think you were trying to write a smarter preprocessor that
sometimes would detect some exceptional conditions earlier than a dumb
preprocessor, but will not be as robust, portable, or intuitive.
> 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.
Yeah, and leave the unsuspected user wondering why on earth Squid
says that "foo.cfg, bar.cfg, bar10.cfg" is a loop!
You would have to explain the user (in the error message) that you
suspect that "foo.cfg" and "bar10.cfg" are really the same files
because one is a link to the other or something like that.
Clearly, a "foo.cfg, bar.cfg, bar10.cfg, bar.cfg" is a much more
obvious loop. It would be up to the user to find out why both
"foo.cfg" and "bar10.cfg" include "bar.cfg", but the course of actions
should be clear for any sane user, on any platform.
> 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?
See above. That's what -I options are for. Cannot do a preprocessor
without them.
> If user has ability to create multiple links to the same file, then
> he already must understand the matter.
The link creator may not be the same person who is running Squid.
> 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.
Absolute or relative, it does not really matter. I should have
realized that earlier. Sorry.
Preprocessors iterate -I directories. One of those directories may be
"current directory" or another relative directory, but it does not
matter. You can still compare dir+filename strings and detect a loop.
My point is that all you need to do to detect a loop is to compare
dir+filename strings, that's all. Yes, in some corner cases, you might
be able to detect a loop earlier, but that is not an essential
feature, especially given its complications and limited scope.
[ N.B. For a daemon application like Squid it is a bad idea
to use relative directories in -I statements (or by default). ]
> 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.
I do not think that supporting fast recovery or swappable disks is a
task of a configuration language pre-processor. Configuration language
pre-processor should only be concerned with pre-processing
configuration files. If it cannot, for whatever reason, it should quit
with an error, leaving the caller to handle the problem (possibly in
an automated way).
Alex.
Received on Mon Apr 01 2002 - 11:36:09 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:55 MST