Bug 112658 - [smbfs] [patch] smbfs and caching problems (resolves bin/111004)
Summary: [smbfs] [patch] smbfs and caching problems (resolves bin/111004)
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2007-05-14 16:20 UTC by Ganael LAPLANCHE
Modified: 2022-10-17 12:36 UTC (History)
2 users (show)

See Also:


Attachments
file.diff (10.57 KB, patch)
2007-05-14 16:20 UTC, Ganael LAPLANCHE
no flags Details | Diff
patch-smbfs-svnrev-246938.txt (8.52 KB, patch)
2013-02-20 07:16 UTC, Ganael Laplanche
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ganael LAPLANCHE 2007-05-14 16:20:02 UTC
This PR includes a patch for PR bin/111004.

I've encountered caching problems with smbfs mounts when the server is case-insensitive (e.g. with 'case sensitive = no' in smb.conf on the server - no problem with 'case sensitive = yes'). Sometimes, a wrong entry is created in the cache and does not match the real filename's case on the server. This happens because the server answers : 'yes, the file exists' while it has a different case. Sometimes then, this cache entry is found and used (because of cache's case-sensitiveness), while it should not. 

----
Here is a test you can perform (on a smbfs mount point) :

$ touch foo && rm -f foo && touch FOO && rm -f FOO
This is to purge cache entries explicitly.

$ touch foo && ls -i foo
2864008422 foo
$ ls -i FOO
2864008422 FOO
This is OK since we should see the inode of foo.

$ rm -f foo
$ touch FOO && ls -i FOO
2864008422 FOO
Nope, we should get another inode (2322004806) since inodes depend on the filename and the parent directory. Here, a wrong cache entry has been used.

$ rm -f FOO
$ touch FOO && ls -i FOO
2322004806 FOO

This is OK again (because the cache entry has been explicitely removed before).
----

The attached patch is inspired from Opendarwin's code and uses the filename provided by the server when the file is found (instead of using the requested filename that may differ). This allows a better cache synchronization and solves this inode/caching problem.

Moreover, I've added a fix for PR bin/111004 which now allows to modify the case of a file (to 'rename' it).

This patch applies cleanly (and works ;-)) on 6.2-STABLE. It also applies to -CURRENT, but I have not tested it on this version.

Best regards,

--
Ganael LAPLANCHE.
ganael.laplanche@martymac.com
http://contribs.martymac.com

Fix: Patch attached with submission follows:
How-To-Repeat: Try the test above.
Comment 1 Ganael LAPLANCHE 2007-05-21 14:40:45 UTC
Hi,

I've just tested the patch on -CURRENT. Everything went OK :)

Ganaël LAPLANCHE
ganael.laplanche@martymac.com
http://www.martymac.com
Comment 2 Craig Rodrigues freebsd_committer freebsd_triage 2007-07-26 03:24:18 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs
Comment 3 Ganael Laplanche 2013-02-20 07:16:27 UTC
Here is an updated version of the patch.
It applies to svn revision 246938.

--
Ganael LAPLANCHE <ganael.laplanche@martymac.org>
http://www.martymac.org | http://contribs.martymac.org
FreeBSD: martymac <martymac@FreeBSD.org>, http://www.FreeBSD.org
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:50:07 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 5 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:36:15 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>