om_utils_get_parent_path_from_uri adds extraneous slash at the end of returned path
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OBEX FTP Client for GNOME-VFS |
New
|
Undecided
|
Unassigned |
Bug Description
function om_utils_
parent_path = g_strconcat (tmp, "/", NULL);
thus, it will always return a path with an extra slash at the end.
Now, I dont know what is the reason for this, maybe it is needed somewhere, but this behavior breaks optimization in function
om_get_
if (path && conn->current_dir && strcmp (path, conn->current_dir) == 0 && conn->current_
{
// return already cached listing
}
The problem is that often, variable 'path' has been filled up by a call to om_utils_
and 'conn->current_dir' has been filled up by a call to om_utils_
The first function adds extraneous slash, the second doesnt, thus check 'strcmp(
the paths are really the same, for example '/' and '//', or '/C:' and '/C:/'.
It appears that the only possible reason why om_utils_ get_parent_ path_from_ uri() adds the slash is in function get_path_ list_from_ uri() from src/om-utils() : it was probably feared that the call
om_utils_
( where new_path might have been returned by om_utils_ get_parent_ path_from_ uri() ) would not have the slash in between.
This reason is bogus, because om_utils_ get_parent_ path_from_ uri() essentially does nothing else but calls om_utils_ get_path_ from_uri( ).
Now we have 2 possibilities:
1) either om_utils_ get_path_ from_uri( ) always returns path with a slash at the end
( my debugging suggests that this is the case ) in which case we have no problem
2) or it does not, in which case adding an extra slash in om_utils_ get_parent_ path_from_ uri() get_path_ from_uri( )
does not help anyway, because 'new_path' might have been returned by om_utils_
in which case we still have a problem.
Conclusion: remove the call to g_strconcat(), win efficiency.