Re: includes inside squid.conf

On Tuesday 02 April 2002 14:51, Andres Kroonmaa wrote:

> Whats the matter with you? Why are you attacking me in almost
> insulting manner? If I'm missing something, show me. Supercilious
> waiving from above isn't very helpful. I still don't see my error.

Sorry if you did not see the joke.

> > > complex junk?? if (stat(file_name, &sb) if
> > > (sb.st_ino==seen_ino) fail()}
> >
> > a) The above code is not correct. You are missing important parts
> > of the inode identity in order to compare two inode numbers. Go
> > back and read on what an inode and inode number is ;-)
>
> From stat() manpage:
> st_ino
> This field uniquely identifies the file in a given
> file system. The pair st_ino and st_dev uniquely
> identifies regular files.
>
> The above wasn't meant to be correct code, its a pseudocode I
> tried to fit on single line. As well you could have said that
> indenting wasn't correct.
>
> Whats wrong with comparing st_ino/st_dev pair on unix?

Good. Now you show the mostly correct picture. Inode number alone is
not sufficient, you also need to make sure the filesystem is the same
(device number).

There is noting wrong with this in theory, except for the small fact
that stat() won't actually return unique inodes or device numbers on
most UNIX:es today due to 64 bit transition of the filesystems and
stat() beeing stuck with a 32 bit interface by default..

> > b) stat() is not at all portable, not even within the different
> > UNIX flavors or different variants of the same UNIX flavor.
>
> And yet we do use stat() and rely on it _alot_.

We use stat() to check timestamps only. Not devices or inodes.

Should perhaps mention that timestamps are plauged by the same
problem, but not as apparent yet.. (those are also being transitioned
from 32 to 64 bits).

> > Not portable within UNIX flavors as there are filesystems and
> > systems using inode identities not compatible with the normal
> > stat() call, requiring you to use the non-standardized stat64()
> > call if available to get the full picture..
>
> We don't need full picture. All we need is that ino/dev pair is
> unique for any file.
> What examples can screw my assumptions?

The fact that the return value of stat() do not return unique pairs
on most systems today except given very specific conditions.

> We don't need to bother with these aspects if source is compiled
> on given system. The 32/64 sizes are hidden from us by system
> includes, isn't it? Again, we don't need to use the inode value,
> we just rely on it being unique. If its provided to be unique
> then we don't even care what its fs-specific identity is.

No, the 64/32 bit issue is not hidden at all. It is very much there.
The 64 bit values in the filesystems is simply truncated to 32 bits.
This truncation makes it no longer a unique value.

Most UNIX:es today have a serious case of split personality between
32 and 64 bit interfaces, where the 32 bit interface is only
guaranteed to provide correct functionality within it's bounds and
the 64 bit interface is not enabled by default. Usually, as long as
you limit your filesystem sizes, device numbers, user identities,
file sizes etc to their old assumed upper boundaries the 32 bit
interfaces works, but in precense of large filesystems, high user
id's, large files etc the 32 bit interfaces fails and returns either
truncated information or the maximum available in the 32 bit
interface.

Regards
Henrik
Received on Tue Apr 02 2002 - 06:43:51 MST