Modification time is not kept when copying or moving

[batagy]

Describe the bug
In February 2026, I had a Feature request to keep file & folder modification time when copying. See #457 and #458

It was implemented and tested with v19.6.8 at the time, when it worked nice.

Recently I've noticed that it doesn't work. I tested in v19.20.0. Both moving and copying files and folders, will modify the mtime on target as current time.

Was that feature discontinue or is this expected? If expected, why?
If not expected, can you please revisit the feature?

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• Version (cloudcmd -v): v19.20.0
• Node Version node -v: 26.7.0
• OS (uname -a on Linux): Debian 13 (Linux openmediavault 7.1.8+deb13-amd64)
• Browser name/version: Firefox 154.0
• Used Command Line Parameters: Nothing special, default docker image used.
• Changed Config:

services:
  web:
    image: coderaiser/cloudcmd
    ports:
      - 8010:8000
    user: "1002:100"
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/cloudcmd:/root
      - /srv/dev-disk-by-uuid-3c8c08fb-e33c-4e9f-b5d0-9584861386fd/media:/mnt/fs/media
      - /srv/dev-disk-by-uuid-05f6862b-1f41-48ce-a08b-358f32f713a5/backup:/mnt/fs/backup
      - /media/usbdevices/:/mnt/fs/usbdevices:rshared
    restart: unless-stopped
    environment:
      CLOUDCMD_THEME: light
      CLOUDCMD_ROOT: /mnt/fs
      CLOUDCMD_CONFIG_AUTH: false
      CLOUDCMD_AUTH: false

In donated via Opencollective on March 02, 2026.

Additional context
Add any other context about the problem here.

[coderaiser]

Last time we fixed copying, move wasn't touched. Just updated and landed in v19.20.1 🎉.

Is it works for you?

[batagy]

Hi.
I tested v19.20.1.
Unfortunately keeping mtime does not work neither for copy, nor for move.
György

[batagy]

Hi
I'm sorry it is maybe my fault. It seems my disk doesn't allow timestamp modification.
I'll check and let you know.

[batagy]

The issue was on my side, I had wrongly mounted disk.
I'm sorry for troubling unnecessarily!

So with v19.20.1 re-tested:

• Copying keeps mtime as expected. No issue.
• Moving however does not keep modification times. Evven after your latest change.

Can you check it please?
Thanks
György

[coderaiser]

I cannot reproduce this, do you move from one partition to another or in the same partition?

[batagy]

In both case , I copied and moved to separate disk.
Now I re-tested moving again with v19.20.1:

• Moving inside one partition: keeps mtime properly.
• Moving to different disk: does not keep mtime.

[coderaiser]

is it only files or directories as well?

Could you provide reproducible list of files as small as possible

[batagy]

mtime is not kept for both files and folders when moving to different disk.

I'm not sure how providing files would help. It should be reproducible with any files and subfolders
Can't You reproduce it even with different disk when moving folders?

EDIT: I'm moving files and folders from internal EXT4 SSD to USB attached NTFS disk mounted, if that matters. The NTFS disk is mounted so that every user has permission to write folders and files and can change mtime. (Copying to the same works properly.)

[coderaiser]

if you move even 1 file mtime is not preserved, right?

[batagy]

Yep, mtime is not preserved even for 1 file move.