Benedict's experience, using "dint" as samba server (samba-3.0.28 on 
gentoo) with a win-xp client for viewing and WinSCP for creating 
things.

'New Folder' existed on ext3 shared with samba.
Created 'New folder' by WinSCP. Copied thing into it.
Check via samba from winxp; saw two; both had same contents, that of the 'F'.
Move 'New Folder' to recycle bin on local client.
Check remaining 'New folder'; only the content of the newly copied thing shows.
Check recycle bin: nothing there (and 'move' took short time - not a 7GB copy).
So, it's cocked up.



Test again, on gnu (in order to play about with settings without
disturbing other people) with same samba version, creating things locally
and viewing from prosit.ets.kth.se (win2000server).

Made 
mkdir New new
touch New/Capitals
touch new/littles
mkdir New/Even_Newer
touch New/Even_Newer/.n

Viewed from the client: saw the two directories, with 'new' first in the 
list (why?!). Both New and new showed same content: that of new.

Dragged new to desktop from network explorer window (it copied, rather
than moved).  Then dragged again, to Recycle-Bin.  The confirmation dialogue
asked "Are you sure... to delete [and all of its contents]" rather than 
just "Are you sure... move to "; tried also with the local copy of new, 
which just went straight to the bin, without question: so there's SOME
sort of warning about actually deleting rather than copying.

Then, the remaining New on the network showed the proper contents.

So -- the problem has been reproduced.



Now reconfigure the server so that in:
  preserve case = yes
;  short preserve case = no
# Default case is normally upper case for all DOS files
;  default case = lower
# Be very careful with case sensitivity - it can break things!
;  case sensitive = no

the 'case sensitive' option is set to 'yes'.
The above steps were repeated, and it worked fine; both new and New 
could be accessed, showing their real contents rather than those of 
the first-case-insensitive-matched name.

The potential problem with this setting is presumably programs that 
expect to find files without needing to get the case right: this 
was checked by trying to access nEw, which [rightly] gave "does not exist".
So, probably better just to keep it as it was.  After all, the really
nasty matter of loss of data only occurred throught a further problem
of recycle-bin behaviour depending on the source filesystem (local 
or network).