Repository: minio/minio (language: go)

Issue:
Copying file over itself does not update "Last Modified" date
## Expected Behavior
Copying file over itself should update its "Last Modified" field (i.e. `mc cp minio/bucket/file minio/bucket/file`)

## Current Behavior
Latest versions of the docker images for `minio` (starting from `RELEASE.2023-10-24T04-42-36Z`) stopped to support this feature.
Also, when I was trying to update the file metadata via AWS S3 SDK - the behavior was the same.

## Steps to Reproduce
I have the following docker-compose configuration:
```
version: '3.7'

services:
  minio:
    image: quay.io/minio/minio:RELEASE.2023-10-25T06-33-25Z

    # Working version
    #image: quay.io/minio/minio:RELEASE.2023-10-16T04-13-43Z

    command: server --console-address ":9001" /data
    expose:
      - "9000"
      - "9001"
    hostname: minio
    volumes:
      - miniodata:/data

  mc:
    image: quay.io/minio/mc:RELEASE.2023-10-24T21-42-22Z
    hostname: mc
    entrypoint: /bin/sh
    command:
      - -c
      - |
        # wait for service
        sleep 3
        mc config host add minio http://minio:9000 minioadmin minioadmin
        mc mb --ignore-existing minio/bucket
        # add file and get its metadata
        echo ">>> Creating the file"
        echo "testdata" | mc pipe minio/bucket/testfile
        echo ""
        mc stat minio/bucket/testfile
        echo ">>> Sleeping for 5 seconds..."
        sleep 5
        echo ">>> Copying the file over itself"
        mc cp minio/bucket/testfile minio/bucket/testfile
        mc stat minio/bucket/testfile

volumes:
  miniodata:
```

`mc` container creates the file, sleeps a little bit and copies the file over itself. On each step the container prints file info.

```
mc_1     | Added `minio` successfully.
mc_1     | Bucket created successfully `minio/bucket`.
mc_1     | >>> Creating the file
mc_1     | Name      : testfile
mc_1     | Date      : 2023-10-25 16:28:52 UTC 
mc_1     | Size      : 9 B    
mc_1     | ETag      : 0a6ffabc2c574388eef7a08f4360b67b-1 
mc_1     | Type      : file 
mc_1     | Metadata  :
mc_1     |   Content-Type: application/octet-stream 
mc_1     | 
mc_1     | >>> Sleeping for 5 seconds...
mc_1     | >>> Copying the file over itself
mc_1     | `minio/bucket/testfile` -> `minio/bucket/testfile`
mc_1     | Total: 9 B, Transferred: 9 B, Speed: 1.83 KiB/s
mc_1     | Name      : testfile
mc_1     | Date      : 2023-10-25 16:28:52 UTC 
mc_1     | Size      : 9 B    
mc_1     | ETag      : 0a6ffabc2c574388eef7a08f4360b67b-1 
mc_1     | Type      : file 
mc_1     | Metadata  :
mc_1     |   Content-Type: application/octet-stream 
mc_1     | 
```
As you can see, despite the `sleep 5` before `mc cp` command,  the `Date` has not changed: `2023-10-25 16:12:13 UTC`

**Correct behavior:**
The expected behavior could be reproduced after downgrading `minio` to the tag `RELEASE.2023-10-16T04-13-43Z`:
```
mc_1     | >>> Creating the file
mc_1     | Name      : testfile
mc_1     | Date      : 2023-10-25 16:17:47 UTC 
...
mc_1     | 
mc_1     | >>> Sleeping for 5 seconds...
mc_1     | >>> Copying the file over itself
mc_1     | Name      : testfile
mc_1     | Date      : 2023-10-25 16:17:52 UTC 
...
```
You can see here the `Date` difference: 2023-10-25 16:17:47 UTC  vs 2023-10-25 16:17:52 UTC 

## Context
I use my bucket as a cache bucket that has a recycle policy that cleans the bucket from the old files when they are stopped to be used. Also I have a special software that refreshes the `Last Modified` date if the file is used by other services (by copying over itself).

## Regression
Looks like regression because I have tested some versions and found out that`RELEASE.2023-10-24T04-42-36Z` has such issue and `RELEASE.2023-10-16T04-13-43Z` not.




Discussion / hints:
@0rps it looks like are preserving the mtime from the source. We will fix it. 
is your bucket versioned or unversioned? 
> is your bucket versioned or unversioned?

Hi, thanks for the reply. The bucket is an unversioned one (created via plain `mc mb %bucketpath%` command )
yeah found the fix, looks like this has been around for ages. It was simply uncovered because of this #18285 

Fixing it correctly under all situations. 

Fix patch:
diff --git a/cmd/erasure-object.go b/cmd/erasure-object.go
index f3f97a7b10f7a..45d2822b9193c 100644
--- a/cmd/erasure-object.go
+++ b/cmd/erasure-object.go
@@ -132,15 +132,18 @@ func (er erasureObjects) CopyObject(ctx context.Context, srcBucket, srcObject, d
 			versionID = mustGetUUID()
 			fi.IsLatest = true // we are creating a new version so this is latest.
 		}
-		modTime = UTCNow()
 	}
 
+	modTime = UTCNow() // We only preserve modTime if dstOpts.MTime is true.
+	// in all other cases mtime is latest.
+
 	fi.VersionID = versionID // set any new versionID we might have created
 	fi.ModTime = modTime     // set modTime for the new versionID
 	if !dstOpts.MTime.IsZero() {
 		modTime = dstOpts.MTime
 		fi.ModTime = dstOpts.MTime
 	}
+
 	fi.Metadata = srcInfo.UserDefined
 	srcInfo.UserDefined["etag"] = srcInfo.ETag
 


Test patch: