I did the following operation.

Created a 2*2 distributed-replicated volume. mounted the volume in two separate machines.
from 1st client - mkdir amd
from 2nd client - stat amd

Now I took down a node and took it back up. 
from 1st client - rmdir amd
from 2nd client - stat amd

Now in backend I see that 'amd' directory is having sticky bit.
[root@Engg-Lab15 testmount]# ls -l /tmp/brick1/
total 0
---------T 1 root root 0 Aug  3 00:33 amd

This issue was originally observed in enomaly set-up. And vm creation fails when I do similar kind of operation using enomaly UI.

I saw this log entry in second client log

[2011-08-03 00:33:20.643113] I [client-handshake.c:852:client_setvolume_cbk] 0-hosdu-client-3: Connected to 10.1.12.113:24009, attached to remote volume '/tmp/brick4'.
[2011-08-03 00:33:20.643141] D [client-handshake.c:737:client_post_handshake] 0-hosdu-client-3: No open fds - notifying all parents child up
[2011-08-03 00:33:20.643163] D [fuse-bridge.c:3334:notify] 0-fuse: got event 8 on graph 0
[2011-08-03 00:33:42.359208] D [dht-common.c:458:dht_lookup_everywhere_done] 0-hosdu-dht: linking file /amd existing on hosdu-replicate-1 to hosdu-replicate-0 (hash)
[2011-08-03 00:33:42.359247] D [dht-linkfile.c:138:dht_linkfile_create] 0-: dict is NULL, need to make sure gfid's are same
[2011-08-03 00:33:42.359801] D [afr-transaction.c:1029:afr_post_nonblocking_entrylk_cbk] 0-hosdu-replicate-0: Non blocking entrylks done. Proceeding to FOP
[2011-08-03 00:33:42.360141] W [fuse-bridge.c:145:fuse_entry_cbk] 0-glusterfs-fuse: 7: LOOKUP() /amd returning inode 0
[2011-08-03 00:33:42.360831] D [afr-lk-common.c:410:transaction_lk_op] 0-hosdu-replicate-0: lk op is for a transaction
[2011-08-03 00:33:42.360983] W [fuse-bridge.c:184:fuse_entry_cbk] 0-glusterfs-fuse: 9: LOOKUP() /amd => -1 (No data available)