Bug 1204140

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

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

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

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. ***