Sync-plan creates "content" directory

[akleber]

In a Real-time sync plan I specified the destination like so:

I am expecting the source files to be placed in a directory "nas" on the "nas-backup" SFTP storage.
However everything is placed in "nas/content" in the destination

The running rclone process is called like this:
/opt/pluton/binaries/linux-x64/rclone sync /source nas-backup:nas/content --fast-list --delete-excluded --links -v --checksum --use-json-log

I think the "/content" part should not be there.

[towfiqi]

This is actually a feature, not a bug. haha. Let me explain.

The content is stored in the content folder because there is a file revisions feature with the sync plan. So, regardless of whether file revisions are enabled or disabled, on sync plans, the destination storage stores the data like this:

Storage Destination/
├── content/
│ ├── MyFile.txt
│ ├── AnotherFile.mp4
│ └── OtherFile.json
├── history/ (history folder only appears if the file revisions option is enabled)
│ ├──2025-08-16T06-45-00-009Z/
│ └─── MyFile.txt

When the file revision option is enabled, when a file is changed in the source, and before running the sync action for the storage destination to sync the source file, the file in storage gets copied into the history folder within a dated folder (e.g., 2025-08-16T06-45-00-009Z). Then the sync action is carried out, and the storage destination mirrors the actual files in the storage. And now the previous copy of the file before the change is stored in the history folder. In the above diagram, the Myfile.txt was changed in the source. If the file revisions option is enabled, when the sync action is carried out, the MyFile.txt file is moved from the storage destination's original path to a history/2025-08-16T06-45-00-009Z folder, and then the updated MyFile.txt is synced from the source to the original path. Currently, when enabled, this happens for all the files. A few options, like include/exclude, will be added to customize this revision feature in the future. If the file revisions option is disabled, there is no history folder in the storage destination.

Now, the reason the content is stored in a content folder, regardless of whether the revision feature is enabled or disabled, is that it gives users the ability to turn on the file revisions option anytime they want. If the source content was directly written in the storage destination path, that would not be possible.

Does storing your data in a "content" folder inside your storage destination cause any issues or break any workflow?

[akleber]

Thanks for the explanation. I have to admit that I did not read the documentation about sync before. However the "content" folder is not mentioned, only the "history" folder. A suggestion would be to add what you described above to the documentation.

I understand the reason for the "content" folder (enabling/disabling it anytime) and I have no good suggestion how to handle that. But Pluton behaved unexpectedly for me which is not optimal from a user experience point of view. The "Source & Destination" tab of the sync plan could mention the "content" folder at the target location, and the "history" folder in the "advanced" tab when enabling revisions.

Thinking about my use case I actually like the feature of revisions (the history folder). I did not really notice that before.

My initial idea was to use a second Synology NAS, which is a sync of the primary one, as one of my backups. So when the primary one becomes unavailable, I could just use the secondary one as direct replacement for the primary.
The issue with the "content" folder is, that I cannot specify the share name of a shared folder with Synology OS. So I cannot share the "content" folder with the same name as it is on my primary NAS, which is simply "NAS". But this is Synology specific.

In summary: I like the revision feature, I do not like the "content" folder and I have no good idea how to solve that elegantly with Synology NAS.

[towfiqi]

I don't have much knowledge about the Synology NAS ecosystem, but I will investigate if there is a workaround for this. If there is no workaround, maybe rethink how the content is stored in the destination storage.

[towfiqi]

@akleber Make sure you have the revisions option disabled. Otherwise, for a large source its going to cause issues.

And after much though I have decided to refactor how the content is stored in the storage destination. The content will be stored in the root storage destination, as intended by the user. But the revision content will be stored in a root ".pluton" directory. Since after this refactor, any existing sync plan might break, it's better to avoid creating any sync plan right now and wait for the next release.

[akleber]

This sounds like a good idea. Happy to try when it is available.

[towfiqi]

Sync plan has been refactored in v0.13.0.

Sync plan now copies your source content to the root of your storage destination path. And the revision feature has also been refactored. But the revision feature should only be used for a sync source folder that has fewer than 10k files. Here are all the features, bug fixes related to sync plans:

• refactor: Sync plan now copies your source content to the root of your storage destination path.
• refactor: How the sync revision mechanism works. (will add documentation shortly)
• feature: Ability to schedule long intervals for sync plans
• feature: sync backup progress tracking & sync cancellation mechanism
• feature: File/folder exclusion feature for sync plans with glob patterns.