samba - Sep 2000 - 2.0.7: smbmount/smnfs issue

Urban, I see you're monitoring this list, so here is a long standing
problem related to smbmount/smbfs :-)

If:
- someone has and HD (Win9x) where the volume label of the HD is "Xyz"
- there is a dir "c:\Xyz", 
- the c:\ rootdir is shared (say as "c")
Then when the HD is smbmounted the c:\Xyz dir will appear as a file
(really as a "VOLUME ARCHIVE" looking at smb-tcpdump) and not a dir,
its
content won't be available.
To solve this either change the volume label or the dir name.
Smbclient in not affected.
This is real-time, if you change the volume label while the disk is
smbmounted you see the dir re-becoming a dir and vice-versa.

My setup:
Linux RedHat6.1
Kernel 2.2.14 + your smbfs-nls-2.2.14.patch
samba-2.0.7 not patched for anything related to smbmount.

Thanks.

-- 
giulioo@pobox.com

On Wed, 20 Sep 2000, Giulio Orsero wrote:
> Urban, I see you're monitoring this list, so here is a long standing
> problem related to smbmount/smbfs :-)
I know, I have a saved copy of your "2.0.7pre3: smbmount issues" mail
(Yes, I save all sorts of junk mail ;-) but it doesn't crash or destroy
anything so it hasn't received a timeslice yet.
> If:
> - someone has and HD (Win9x) where the volume label of the HD is
"Xyz"
> - there is a dir "c:\Xyz", 
> - the c:\ rootdir is shared (say as "c")
> Then when the HD is smbmounted the c:\Xyz dir will appear as a file
> (really as a "VOLUME ARCHIVE" looking at smb-tcpdump) and not a
dir, its
> content won't be available.
> To solve this either change the volume label or the dir name.
> Smbclient in not affected.
I'll try to have a look this evening.

/Urban

On Wed, 20 Sep 2000, Giulio Orsero wrote:
> If:
> - someone has and HD (Win9x) where the volume label of the HD is
"Xyz"
> - there is a dir "c:\Xyz", 
> - the c:\ rootdir is shared (say as "c")
> Then when the HD is smbmounted the c:\Xyz dir will appear as a file
NT4 doesn't do this, but win95(?) does.
> (really as a "VOLUME ARCHIVE" looking at smb-tcpdump) and not a
dir, its
> content won't be available.
Yes, AA is a dir and also the volume label:

smb_proc_do_getattr: //AA
smb_finish_dirent: fattr: attr=00000028

0x28 means aARCH | aVOLID, however aDIR (0x10) is not set. Funny.

smb_proc_getattr_{core,ff,trans2} all have the same problem (ff doesn't
work with win95 it seems). Time to check what smbclient does ... the
difference is that smbclient actually uses all the information returned by
the "findfirst" command. smbfs throws away everything but the
filename.
This is what findfirst returns.

smb_decode_long_dirent: info 260 at c8862b34, len=2, name=AA
smb_decode_long_dirent: attr=00000010

smbfs has to create inodes so even if it used the findfirst information it
would still end up doing a getattr call when it needs to "refresh" the
inode.

So why not use findfirst to read the attr? Well, that is what
smb_proc_getattr_ff does, except it uses infolevel 1 and not 260. And I
can't get win95 to be happy with my requests to do findfirst260 on the
path "\".

Below is a workaround for this, it assumes that you never read a file with
the "volid" bit set. patch vs 2.2.14, for 2.4.0-test8 and 2.2.18pre
you
need to replace 'version' with 'flags' and SMB_FIX_WIN95 with
SMB_MOUNT_WIN95.

The proper fix would be to modify getattr, but I don't know how.

/Urban


diff -urN -X exclude linux-2.2.14-orig/fs/smbfs/proc.c linux/fs/smbfs/proc.c
--- linux-2.2.14-orig/fs/smbfs/proc.c	Tue Jan  4 19:12:23 2000
+++ linux/fs/smbfs/proc.c	Wed Sep 20 20:13:51 2000
@@ -1256,6 +1256,11 @@
 static void
 smb_finish_dirent(struct smb_sb_info *server, struct smb_fattr *fattr)
 {
+	/* workaround for win95 giving back a volume label and not a directory
+	   if there is a dir with the same name as the volume label. sigh. */
+	if ((server->mnt->version & SMB_FIX_WIN95) &&
(fattr->attr & aVOLID))
+		fattr->attr |= aDIR;
+
 	fattr->f_mode = server->mnt->file_mode;
 	if (fattr->attr & aDIR)
 	{