Re: [2.6] smbfs & "du" illness

[Linus Torvalds]

On Sat, 25 Sep 2004, Jeremy Allison wrote:
> 
> Right now (Samba 3.0.7) you are correct. But the intent is
> to fix it going forward, so that in non-broken server implementations
> (yes the Samba implementation is broken right now) then it
> will be correct (ie. follow the intent of the spec).
> 
> Sorry, can't fix the past, I can only fix the future :-).

So let's work out something that works well now, _and_ might have a chance 
in hell of working in the future too.

What kinds of values do different smb servers actually fill this field 
with? And what's the value you expect future samba severs will use?

Ie, will something like this DTRT in smb_decode_unix_basic():

	u64 size = LVAL(p, 0);	/* file size */
	u64 blocks = LVAL(p, 8); /* pseudo-blocks */
	u32 real_blocks;

        fattr->f_size = size;
	real_blocks = (size + 511) >> 9;

	/*
	 * old samba sends "bytes used on disk rounded up to 1MB",
	 * which is useless - ignore it. But if the low bits are
	 * set, maybe the value is valid..
	 */
	if (blocks & 0xfffff) {
		/*
		 * If the low 9 bits are non-zero, it can't
		 * be a byte count, but maybe it's a block
		 * count?
		 */
		if (blocks & 0x1ff) {
			.. use it how? ..
		} else {
			real_blocks = blocks >> 9;
		}
	}
        fattr->f_blocks = real_blocks;

the above is ugly as hell, but what choice is there?

It would be good to know what all different server implementations can 
do, to know just _how_ defensive this code has to be. 

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/