nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Preserve folder modification dates during Dropbox updates and metadata refreshes

pentagramwookie

Many professionals rely on Finder's Date Modified column to quickly identify active projects. Currently, Dropbox desktop updates or metadata refreshes can cause thousands of folders to receive the same "Date Modified" timestamp, even though the folder contents have not changed.

This effectively wipes out one of the most useful organizational tools in Finder. After an update, every project folder appears to have been modified at the same time, making it much harder to find current work until enough genuine file activity accumulates.

Idea:

Dropbox should preserve existing folder modification dates unless the contents of a folder have actually changed. Internal sync operations, desktop app updates, File Provider migrations, or metadata refreshes should not alter the modification date presented in Finder.

This would greatly improve the experience for designers, photographers, developers, musicians, video editors, and anyone who manages large numbers of project folders by sorting on Date Modified.

Maintaining accurate modification dates would preserve established workflows while making Dropbox updates much less disruptive.

This idea has been discussed by the Dropbox community for years.

My previous discussion:
https://community.dropbox.com/en/discussion/853647/loss-of-reliable-date-modified-behavior-is-destroying-file-discovery-and-productivity#latest

Another discussion:
https://community.dropbox.com/en/discussion/comment/788910#Comment_788910?utm_source=community-search&utm_medium=organic-search&utm_term=date+modified

A discussion from a user who chose not to use Dropbox because of this behavior:
https://community.dropbox.com/en/discussion/comment/675786#Comment_675786?utm_source=community-search&utm_medium=organic-search&utm_term=date+modified

Another discussion from 2024:
https://community.dropbox.com/en/discussion/comment/800538#Comment_800538?utm_source=community-search&utm_medium=organic-search&utm_term=date+modified

There are several other discussions on the topic as well, which suggests this has affected users across multiple years and workflows.

https://community.dropbox.com/en/discussion/comment/800538#Comment_800538

https://community.dropbox.com/en/discussion/comment/289832#Comment_289832

https://community.dropbox.com/en/discussion/comment/675786#Comment_675786

https://community.dropbox.com/en/discussion/853647/loss-of-reliable-date-modified-behavior-is-destroying-file-discovery-and-productivity

Find more posts tagged with

Desktop

Dateien & Ordner

Mac

Folders

Open

Status: Open

Comments

Neal

Hi @pentagramwookie,

Thanks for sharing such a detailed breakdown of your idea!

I understand the request completely and unfortunately it is known internally that background processes can affect the Modified Date of files and folders.

I've opened this idea up for voting so the rest of the Community can show their support.

pentagramwookie

Thanks for reopening this idea for voting, Neal—I appreciate it.

I wanted to add some additional information that may help narrow down what's happening:

As additional context, on July 5 a large portion of my Dropbox project folders suddenly had their Finder "Date Modified" changed to approximately the same time, despite me not modifying those folders or their contents. This effectively reset the chronological organization of my projects, making Finder's Date Modified sort much less useful for locating active work.

To determine whether this was simply a Finder display issue or whether the underlying filesystem metadata had actually changed, I checked one of the affected folders using Terminal's stat command.

The results showed that the folder's actual modification time (mtime) and metadata change time (ctime) had both been rewritten:

Modified: Jul 5 12:55:37 2026
Changed:  Jul 5 12:55:37 2026

I also confirmed the same result through both ~/Dropbox/HHR and ~/Library/CloudStorage/Dropbox/HHR, which resolve to the same underlying folder.

Additionally, I checked the macOS unified logs for that time period and observed repeated File Provider background activity involving Dropbox's File Provider extension during the same window. While this doesn't prove the root cause, it suggests the folder metadata is being updated during a background operation rather than by user file changes.

Hopefully this additional information is useful to the engineering team. Thanks again for reopening the discussion.