On Sun, Apr 27, 2008 at 05:00:20PM +0400, Igor Mammedov wrote: > Jeremy Allison wrote: > > On Thu, Apr 24, 2008 at 12:04:06PM +0400, Igor Mammedov wrote: > > > >> I'm doing the second call with a short path to get inode info > >> including server generated inode number. If not for the last > >> then second call could be omitted and inode be filled with fake > >> values and locally generated ino. > >> > >> PS: > >> Windows server does not object against the second call and returns > >> info on the dfs junction point (as directory). > >> More uniform behavior between different implementations would be > >> better for all. > > > > Can you try this patch against the 3.2 code please. It should > > cause smbd to return a directory on the short QFILEINFO call. > > Thanks for a patch, I've just tested it. Packets dumps are attached. > > Short summary: > 1. unix extentions are disabled. Works. > * ls on the directory that has a dfs link "dfs2" shows that it is directory > * second QPATHINFO on "\dfs2" returns that it is directory (pkts 28-29) > > 2. unix extentions are enabled. Works partially. > * ls on the directory that has a dfs link "dfs2" shows that it is a link > (pkts 26-27). Would be nice if it was listed as directory here. > * second QPATHINFO on "\dfs2" returns that it is directory (pkts 36-37) > > Traverse over DFS junction point now works in both both cases. Ok, I just had a long chat with Volker about this and he made some good points. With unix extensions enabled doing a QPATHINFO or FINDFIRST with a UNIX info level on /server/share/dfs/path always returns PATH_NOT_COVERED, as it should. Doing a QPATHINFO or FINDFIRST on /dfs/path with a UNIX info level currently returns symlink, which exposes the Samba implementation of the junction. For a Windows info level it returns BAD_PATH, which is a bug in the Samba server and part of my patch trivially fixes this. The question I'm pondoring is - is it correct to spoof this to show a directory when you are querying with a UNIX info level ? On the positive side it hides the Samba implementations. On the negative side it makes it impossible to write code that actually allows the client to see what is really on disk. This goes against the spirit of the UNIX extensions, which is to show straight "posix" on the wire. Now we are in somewhat unknown territory, in that we're defining the interface between UNIX extensions and MSDFS, but if I spoof to show a directory when it's really a symlink I'm lying to clients. If I do the spoof there's no way for clients that want to see the symlink (maybe in order to change it) to do so. I could add some "magic foo" and show the symlink if the QPATHINFO request flags2 doesn't contain the DFS_PATH bit, and show as a directory if it does, but this sucks (and I hate magic foo such as this). I'm inclined as Volker suggested to leave the current behavior with UNIX extensions alone, as the client knows it's dealing with a DFS path (after all the first call got PATH_NOT_COVERED) and it allows the client to code around the discrepancy (as you say traverse over DFS junctions now works with the client) but still allows the UNIX extensions to show what is really on disk in full POSIX glory :-). Steve, others, please comment ! Cheers, Jeremy. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
