|
Bugzilla – Full Text Bug Listing |
| Summary: | cifs mounted directories dont contain . / .. | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Bjoern Jacke <bjacke> |
| Component: | Kernel | Assignee: | Steve French <sfrench> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | asklein, sfrench, suse-beta, vetter |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Bjoern Jacke
2006-02-13 13:33:39 UTC
ah, I overlooked the "Setzen der Zeiten" - so access was not totally denied ;-) But the question for the missing "." and ".." remains. Steve, could you please take a look? I have only seen one case in which a server fails to return . and .. in search results, and I have never seen it with Windows. It would also be useful to see the output of "cat /proc/fs/cifs/DebugData" (that lets us see whether your session is authenticated by the server as "guest" or a real user) and it also might be helpful to see an ethereal trace to see whether the server really failed to return . and .. in the search results or whether those entries were discarded by the client for some unknwon reason Steve: this happens with all XP (tested just SP2) versions if you mount the default C$ disk root share. It should be reproducable for you very easy. If not I'm going to collect and send you more degug data... This seems to be true - Windows server will not return . and .. on a share exporting the root of a drive. Presumably POSIX requires . and .. to be returned no matter what the server says? Also want to verify that this is important enough for me to code around this behavior on the client (ie add code to fs/cifs/readdir.c for inserting . and .. in search results when the server forgets to return them). Steven, do you need more information from Björn? This is fixed in cifs 1.42 (IIRC you have version 1.40 of cifs). The changes to cifs_readdir to fix this and a loosely related search rewind problem were rather large - and rather than make a patch for just these available I will be making a larger update version of cifs 1.44 available later in the week (which also will include NTLMv2 security and some key fixes for POSIX locking which are more important). Could you confirm that this is fixed by the readdir change (which is also in current cifs) which is included in the rollup fixed version: http://us1.samba.org/samba/ftp/cifs-cvs/cifs-1.44.tar.gz This is now fixed in our kernels, right Steve? This was fixed in cifs version 1.42 (I think SLES10 is at 1.44 but will check). My test machine had 2.6.16.11-7 kernel which did not have this fix (it had cifs version 1.40). I don't have a more recent SLES10 build installed (to see if it was picked up as we had suggested) The cifs version 1.44 above (as well as slight more current http://us1.samba.org/samba/ftp/cifs-cvs/cifs-1.45.tar.gz) do have this fix (it was put into mainline with a pair of changesets on 4/23/06). SLES10 has 2.6.16.23 or so. I do not think you upgraded the sifs layer in the stable releases :). So, please backport the fix needed, if you wish to fix this, or close it out as something that you will not support. There are cifs fixes in the stable series, but even stripped down this fix would be a little too large (perhaps 30 lines of code or so) than is typical for the stable release patch and it does not fix a serious enough problem as far as I could tell (it only affects shares of the root of a drive, not all servers have the problem of forgetting to return .. etc.). We will continue to track/test the larger cifs backport for SLES9 and SLES10 service packs (and work with jra etcc) - as there are key fixes in there necessary for 1) NTLMv2 (stronger authentication requirement) 2) marking smbfs obsolete 3) fixing posix byte range locking that are more important (and it includes a rollup of the lower severity bug fixes) but it would be too high risk to break them apart. mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy) mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy) mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy) Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;( |