The problem is mainly caused by the `compareObjects` function inside
`command/sync.go`, where `s5cmd` compares source and destination paths
and extracts files that are present only in the source or destination
path (while also counting nested folders or rather name with its
prefixes) along with common objects. If they both are non-objects, like
wildcard expression, prefix, or bucket, getting relative paths of files
with `src.URL.Relative()` results in compatible and comparable paths. In
this case, no problem is present, at least within the scope of this
issue.

However, when an object is selected as the source, it is not assigned a
relative path using `func (u *url.URL) SetRelative(base *url.URL)`, so
the `src.URL.Relative()` function returns its absolute path.

Let's say the source file has an absolute path of `folder/foo.txt`. The
algorithm compares `folder/foo.txt` with `s3://bucket/remoteFolder/` and
looks for the item `s3://bucket/remoteFolder/folder/foo.txt`. If it does
not match, except for the edge case where there is a duplicate item
inside the searched path, the files never match.

While copying files, `s5cmd` does not use relative paths, so `foo.txt`
is written to the intended path in the remote. However, this happens
during every sync operation, as they do not match.

Problem solved by taking path of source object as its name. This made
algorithm to simply look for matches in destination, a file named
`foo.txt` as intended.

This PR adds new test cases to the sync command. Previously, tests
failed to capture sync command cases where the source is an object in a
prefix, not an object directly in a bucket, or not multiple objects like
a wildcard or prefix expression.

If an object is in the `s3://bucket/` path, its relative path is the
same as its absolute path, so they match during comparison. This
prevented copying the file every time. The new test cases cover all
scenarios.
Resolves: #676.

The problem is mainly caused by the `compareObjects` function inside
`command/sync.go`, where `s5cmd` compares source and destination paths
and extracts files that are present only in the source or destination
path (while also counting nested folders or rather name with its
prefixes) along with common objects. If they both are non-objects, like
wildcard expression, prefix, or bucket, getting relative paths of files
with `src.URL.Relative()` results in compatible and comparable paths. In
this case, no problem is present, at least within the scope of this
issue.

However, when an object is selected as the source, it is not assigned a
relative path using `func (u *url.URL) SetRelative(base *url.URL)`, so
the `src.URL.Relative()` function returns its absolute path.

Let's say the source file has an absolute path of `folder/foo.txt`. The
algorithm compares `folder/foo.txt` with `s3://bucket/remoteFolder/` and
looks for the item `s3://bucket/remoteFolder/folder/foo.txt`. If it does
not match, except for the edge case where there is a duplicate item
inside the searched path, the files never match.

While copying files, `s5cmd` does not use relative paths, so `foo.txt`
is written to the intended path in the remote. However, this happens
during every sync operation, as they do not match.

Problem solved by taking path of source object as its name. This made
algorithm to simply look for matches in destination, a file named
`foo.txt` as intended.

This PR adds new test cases to the sync command. Previously, tests
failed to capture sync command cases where the source is an object in a
prefix, not an object directly in a bucket, or not multiple objects like
a wildcard or prefix expression.

If an object is in the `s3://bucket/` path, its relative path is the
same as its absolute path, so they match during comparison. This
prevented copying the file every time. The new test cases cover all
scenarios.
Resolves: peak#676.