Description of problem: When we have the options "case sensitive = no" and "preserve case = yes" in /etc/samba/smb.conf, renaming a file to a variation of upper and lower case letters of an existing file causes the file that was being renamed to dissapear in the client, and the change to succeed. After umounting and mounting again the samba share, the two versions of the file are visible but only the content of the first one (the one all lowercase) is shown whenever any of them is accessed. For all my tests I first created a file "test.txt" with a very distinctive content, i.e. test1, and followed up with renaming some other files: "test2.txt" with content test2 to "tesT.txt" "tes3.txt" with content test3 to "Test.txt" In both of these cases, the renamed files disappeared, showing only the file "test.txt". When not using the gluster samba vfs plugin, the Windows 7 client is prevented the creation of any file with variations of upper and lower cases of an existing file, showing a windows that reads ' There is already a file with the same name in this location. Do you want to rename "test2.txt" to "new test (2).txt"?' Version: glusterfs-3.6.3beta1-0.11.gitd494bec.el6 How reproducible: Always. Steps to Reproduce: 0. Mount a samba share in a Windows 7 client. 1. Create a file test.txt with any content. 2. Create a second file test2.txt with some different content. 3. Rename test2.txt to tesT.txt. Actual results: test2.txt dissapears completely with both the old name and the new tesT.txt name. Only test.txt is visible. Expected results: A warning is shown that prevents the file to be renamed as a result of the caseless comparison between the existing test.txt and the attempt to rename test2.txt to tesT.txt.
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#1) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#2) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#3) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#4) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#5) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#6) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret.) posted (#7) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret) posted (#8) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret) posted (#9) for review on master by Raghavendra Talur (rtalur)
REVIEW: http://review.gluster.org/9956 (cluster/dht: Unwind with proper op_ret) posted (#10) for review on master by Raghavendra Talur (rtalur)
COMMIT: http://review.gluster.org/9956 committed in master by Shyamsundar Ranganathan (srangana) ------ commit 331e705b6a458600c0b5cbcf2b0f7b9e1167bdc2 Author: Raghavendra Talur <rtalur> Date: Fri Mar 20 18:35:26 2015 +0530 cluster/dht: Unwind with proper op_ret 1. Expected behavior of get_real_filename feature. A getxattr on a existing dir with glusterfs.get_real_filename:<filename> as key should result in one of the following things. a. A value returned for that key having the real filename (a file whose match is a case insensitive match to the filename passed in key). b. op_ret = -1 and errno set to ENOENT meaning that no such file exists under the specified dir in any case. c. op_ret = -1 and errno set to ENODATA. This is a case assuming no xlator interprets the glusterfs.get_real_filename key and it get passed down to the posix xlator. Naturally, posix xlator would not find any xattr with this key and would return ENODATA. This will be interpreted specially by the caller as the feature not being supported by underlying glusterfs. 2. What assumptions are wrong? Initially the key used to be user.glusterfs.get_real_filename. In that case, when posix xlator did a getxattr call it would have received ENODATA as error. However, the key has now changed to glusterfs.get_real_filename. This leads to a EOPNOTSUPP error instead. Considering the above information, this is a rewrite of get_real_filename logic in dht. Change-Id: I012e9150047fc8563be91b0d112a368ac1cbf598 BUG: 1204140 Signed-off-by: Raghavendra Talur <rtalur> Reviewed-on: http://review.gluster.org/9956 Tested-by: Gluster Build System <jenkins.com> Reviewed-by: N Balachandran <nbalacha> Reviewed-by: Shyamsundar Ranganathan <srangana>
REVIEW: http://review.gluster.org/10403 (cluster/dht: Unwind with proper op_ret) posted (#1) for review on release-3.6 by Raghavendra Talur (rtalur)
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report. glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939 [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user
*** Bug 1215596 has been marked as a duplicate of this bug. ***