Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

During a rename, if the new file exists, the old name needs to
over-write the new name. We're returning EEXIST, which is wrong
behaviour.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

In __do_path_resolve, we need to use the new_loc.path as the input
for resolution rather than the resolved variable, simply because we're
not interested in resolving the names that have been resolved, as
pointed out by the variable name 'resolved'. Instead, we need to resolve
new_loc, which stores the next component in the path to
be looked up.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

Not cleaning up the ino member of a loc_t results in SIGABRT
in __inode_link because in some cases, the loc->ino is
different from loc->inode->ino. This happens especially in code
blocks which re-use a loc_t structure for pointing at different
inodes/files. For eg, if a loc_t has been assigned an inode and
an ino, and followed by a libgf_client_loc_wipe, then re-use of this
loc in say libgf_client_lookup results the SIGABRT because
libgf_client_lookup calls inode_link with the same loc_t. However,
this loc_t has just been assigned a new inode pointer but the ino
member still contains a previous inode's inode number. This difference
in inode numbers results in an assertion failure, so the SIGABRT.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

Here I am only refining the entry parsing code in order
to clarify the exit conditions from the loop. There were
a few workloads where this loop went infinite.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>

This commit basically reverts the previous readdir conformance
patch I sent a few days back. That commit had a completely retarded
and broken way of maintaining per-directory dirent.

It was broken for two reasons:
1. Creating a wrapper structure around the directory's fd_t
only for storing a struct dirent is not clean enough. This commit
takes a better approach by storing the dirent in fd_t context.
This dirent is valid only if the fd_t refers to a directory.

2. That commit was made and tested under the assumption (..stupidity
is a better word..) that only opendir call is used for opening a
directory. That is not correct. Directories are also opened using the
open syscall. The point is, glusterfs_open returns an fd_t and so did
glusterfs_opendir. The previous patch actually changed opendir to
return a new wrapper structure. That is fine, if we go by the POSIX
definition of open and opendir because, they're both supposed to
return different types, an int and a DIR*. However, in
libglusterfsclient, all other code assumes that directory handles
corresponding to DIR* and file descriptors corresponding to int types
are the same type, resulting in use of the same locking and fd context
addition/extraction code. So a directory opened using opendir returned
a wrapper structure which went down into the libglusterfsclient stack
where some function called a lock on the handle assuming it was an
fd_t, since it is not and dereferencing of the supposed fd->inode->lock
results in a seg fault.

Obviously, this didnt show up till unfs3 used open() to open a
directory and not opendir.

Signed-off-by: Anand V. Avati <avati@amp.gluster.com>