stat / inode question
Christelle Gibergues
I am currently fighting with some silly software where hard-links are
used.
I want to find those hard links, so used stat to work out the inode
numbers. My problem is that the output of stat($file)[1] seems to be
different from that of a 'ls -i $file'.
Actually, this difference seems to be constant, in that
stat($file)[1] = (ls -i $file) +6
Example :
sun58:[qedchgi]/vobs/ppdc/cctools/src/script > ls -li
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tcl_Sleep.3
666713 -r--r----- 1 qedchgi ppdc 5833 Oct 26 20:26
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tcl_Sleep.3
sun58:[qedchgi]/vobs/ppdc/cctools/src/script > ls -li
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tcl_GetChannel.3
665993 -r--r----- 1 qedchgi ppdc 26849 Oct 26 20:25
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tcl_GetChannel.3
sun58:[qedchgi]/vobs/ppdc/cctools/src/script > ls -li
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tk_NameToWindow.3
667745 -r--r----- 1 qedchgi ppdc 7918 Oct 26 19:39
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tk_NameToWindow.3
Perl script output:
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tk_NameToWindow.3
667751
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tcl_GetChannel.3
665999
/vobs/ppdc/spa_tools/spa_platform/export/man/man3/Tcl_Sleep.3 666719
I'm real confused by this, and don't know which I should trust, stat or
ls -i.
Any ideas why it is different, and if it matters much?
TIA
C-
Elaine Ashton
message news:39F954E8...@eed.ericsson.se...
> I am currently fighting with some silly software where hard-links are
> used.
Clearcase? I've called it a lot worse than silly....
> I'm real confused by this, and don't know which I should trust, stat or
> ls -i.
Unless you built the Perl on that machine yourself, I'd trust ls -i first
and foremost.
> Any ideas why it is different, and if it matters much?
It shouldn't be and yes it matters much. I would guess that something
about your perl compiler is not right. For grins, download a fresh copy,
build it and install it in your home dir or some temp space and try again.
Also, you might post the program you are using which could also be wrong
and misleading you.
e.
nob...@mail.com
> different from that of a 'ls -i $file'.
> I'm real confused by this, and don't know which I should trust, stat or
> ls -i.
I'd get a third oppinion. Write a trivial program on C to print out
the inode field from stat(), or if you have GNU-find you could use the -printf
"%i" option.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
Mark-Jason Dominus
Christelle Gibergues <to...@neuneu.com> wrote:
>I want to find those hard links, so used stat to work out the inode
>numbers. My problem is that the output of stat($file)[1] seems to be
>different from that of a 'ls -i $file'.
Since
stat($file)[1]
is a syntax error, I know you are not telling the truth here.
You are asking us to help you find a bug in your code, but you did not
show us the code. Instead, you showed us something else that you made up.
If you show the *real* code, someone else might see the bug.
If you don't do this, it is impossible for anyone to guess the right answer.
Mark-Jason Dominus
Mark-Jason Dominus <m...@plover.com> wrote:
>If you show the *real* code, someone else might see the bug.
I was rummaging through some old files, and I just happened to find
the following example that shows why it is so useless to report a
problem like this without showing the real code, and so futile for
someone else to try to guess what the real problem is when you have
not done this.
One day someone came into the #perl IRC channel, and they wanted to
know how get the size of an array, so we told them how to do that.
Then a few minutes later, they said `it didn't work'.
Now it's tempting to guess what they did wrong here, but my claim is
that at this point there is no good response except to say `show the
code'.
I want you to try to guess what might be wrong. The write down your
guess. Then peek at the answer below.
Here is the code that they showed:
@result = [my_function()];
$n = @result;
How could anyone have guessed that?
The chance of anyone guessing the actual problem, instead of some other
irrelevant problem, is vanishingly small, because:
FIRST LAW OF PROGRAMMING LANGUAGE SYNTAX
There are ten billion different ways to fuck up.
Mark-Jason Dominus
Elaine Ashton <ela...@chaos.wustl.edu> wrote:
>It shouldn't be and yes it matters much. I would guess that something
>about your perl compiler is not right.
I consulted my File of Good Advice on this one, and it said:
#11907 Looking for a compiler bug is the strategy of LAST resort. LAST resort.
(No, I didn't just make this up; I really do have such a file and it
really does say that.)
On the one hand, there's a chance that the compiler has a broken
'stat' and is subtracting 6 or something. Maybe that sounds likely to
you but it sounds really weird to me. I cannot imagine how such a
thing could possibly occur. Why 6? It all seems very unlikely.
Well, in the absence of an alternative hypotheis, we have to take what
we can get. But in this case, there is an alternative hypothesis!
The alternative hypothesis is that Christelle's program has a bug.
Now, which seems more likely to you?
Weird, inexplicable compiler bug that nobody has ever seen before
or
Programmer fucked up
Hmmm. Let me think.
I'll take Door #2, Monty.
>For grins, download a fresh copy, build it and install it in your
>home dir or some temp space and try again.
This is going to take an hour or two; more if Christelle has never done it
before. And it is a long shot because it is a big bet on Door #1.
>Also, you might post the program you are using which could also be
>wrong and misleading you.
Yes, I like that a lot better.
Good Advice #11907 is unusually good. It has saved me a lot of
trouble in the past.
Elaine Ashton
news:39f9f67d.287e$3...@news.op.net...
> Good Advice #11907 is unusually good. It has saved me a lot of
> trouble in the past.
Indeed, but I've actually experienced a problem like that on a Solaris box
where perl was built on a SunOS box and the blocksize was different but it
still ran due to binary compat. It happens, albeit rare. Stat is so simple
as there is a working example in the man page...ah, well.
e.
Mark-Jason Dominus
Elaine Ashton <ela...@chaos.wustl.edu> wrote:
>I've actually experienced a problem like that on a Solaris box
>where perl was built on a SunOS box and the blocksize was different
Amazing. Did you ever find out why it was subtracting 6 from the i-number?
Maybe the Good Advice file should also include something like this:
#11965 There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
Elaine Ashton
m...@plover.com quoth:
> Maybe the Good Advice file should also include something like this:
>
> #11965 There are more things in heaven and earth, Horatio,
> Than are dreamt of in your philosophy.
I was going to suggest 'Needless pedantry is bad for the bloodpressure'.
e.
Peter Scott
m...@plover.com (Mark-Jason Dominus) writes:
>I consulted my File of Good Advice on this one, and it said:
>
>#11907 Looking for a compiler bug is the strategy of LAST resort. LAST resort.
>
>(No, I didn't just make this up; I really do have such a file and it
>really does say that.)
Can we see the other entries?
--
Peter Scott
Mark-Jason Dominus
I've been including them in my article headers for a while now.