[linux-cifs-client] lstat reporting different inode numbers on smb than it does on other filesystems

[Hein-Pieter van Braam]

OK, I've solved that bit, for some reason after updating my cifs client this 
problem went away, sorry for bothering you, but: alas, the problems don't end 
there. 

lstat also reports different inode numbers over smb than it does over a local 
filesystem.

on ext2/3 and friends, the inod numbers in an lstat are the same for both the 
source and the destination of a hardlink, on cifs, it gets its own inode 
number, that is then passed. 

I've verified this with PHP and by adding some debug information to kdelibs, 
and both confirm that the inode numbers do not correspond.

This leaves me basically in the same spot that I was before, with the KDE 
locking stuff, (mozilla and friends are working now)

I have absolutly verified that I cannot fix this with a newer version of 
cifs-client :)

I'm now building a kdelibs that disables the check for the inode numbers, but 
I don't think that's a good permanent solution, basically, the question is 
still the same :)

what should I look for to fix it? samba or the cifs client?

sorry for repying to myself etc. this must look rather stupid.

greetings,

Hein-Pieter van Braam

On Tuesday 02 November 2004 00:49, Hein-Pieter van Braam wrote:
> hi all!
>
> I've been experimenting with using a samba share as a homedirectory for a
> linux workstation, with nfs security being what it is etc, it seemed the
> best solution for now. This is a production network, and I don't want
> anyone with a knoppix cd and some patience to be able to connect to my
> user's home directories :) nfsv4 with kerberos suppor is to painful at this
> point, and isn't quite ready for prima-time...
>
> Well, chaos ensued after I got pam_mount to run, mozilla wouldn't run, kde
> wouldn't start etc. This was rather frustrating. So I checked all the
> settings for my samba server and confirmed that, everything should be in
> order. and I can do whatever I want on this share as if it was a "real"
> unix-like filesystem (ln, mkfifo mknod etc)
>
> I've tracked this down to (what seems to be) one single problem: an lstat()
> on a smb/cifs mounted volume will always give an nlink value of 1 weither
> or not there are links to that file or not.
>
> This is significant because kde for instance uses the nlink value to
> determine weither or not a lockfile is stale or something, I don't quite
> understand why it does what it does, but I do understand what it does.
>
> If someone wants to check the code out, its in
> kdelibs/kdecore/klockfile.cpp around line 144 (KLockFile::LockResult
> deleteStaleLock)
>
> because the nlink value is 1 and kde expects it to be (rightly so) 2 or
> more, kde won't start, and according to a bunch of straces I did on mozilla
> it does the same thing.
>
> I would really appreciate it if someone could tell me weither this problem
> is because of the cifs client or samba itself. Some pointers as to where to
> begin fixing this would be nice too!
>
> thanks in advance!
>
> Hein-Pieter van Braam.
>
> PS: I have confirmed this behaviour with a very simple php script (was the
> fastest thing I could dream up at that moment) and that shows the same
> output.
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> http://lists.samba.org/mailman/listinfo/linux-cifs-client