Nishant,
CIFS shares and qtrees/data are fundamentally separate entities. A qtree is a folder on disk, in which data is stored, based on security permissions which are also applied to the data (a qtree can therefore have NTFS or NFS permissions applied).
A CIFS share is simply a "published" network path that allows a user to navigate to the qtree/data from a Windows PC.
If you delete a CIFS share (e.g. toaster> cifs shares -delete share1) then all you are simply doing is removing the published network path to the data. You are not touching the data at all.
The data will only be deleted if you delete the qtree and its contents (and you can only delete the qtree if there are no CIFS data shares pointing to it I believe)
As a result, a single location on disk (e.g. /vol/myvolume/myqtree), can have multiple network paths "published" that are pointing to it, e.g.
toaster> cifs shares -add sharename1 /vol/myvolume/myqtree
toaster> cifs shares -add sharename2 /vol/myvolume/myqtree
A CIFS user could therefore map a drive letter to \\toaster\sharename1, and \\toaster\sharename2 and both would be pointing at the same disk/data.
This is why then a CIFS data share cannot be renamed, you have to effectively "un-publish" the original name, and "publish" the new name to the network. The underlying data remains untouched.
We have standards that marry our qtree and AD security group names to the CIFS share name, so if we do a CIFS share rename we have to rename the qtree and security group(s) as well, but that's purely a working practice and will vary from one customer to another.
Adrian