Seafile backend: support for modtime?


First a big thank you for writing rclone, it is awesome!

I have a question regarding the Seafile backend: apparently it does not support ModTime as per the storage overview

My use case is to sync Veracrypt containers, which are basically files of fixed size which only mtime would change when you change something 'inside' the container file. Currently as the Seafile backend only checks the filesize, changes are not caught.

However, the Seafile API and the current code seem to provide these modification times:


// Object describes a seafile object (also commonly called a file)
type Object struct {
	fs            *Fs       // what this object is part of
	id            string    // internal ID of object
	remote        string    // The remote path (full path containing library name if target at root)
	pathInLibrary string    // Path of the object without the library name
	size          int64     // size of the object
	modTime       time.Time // modification time of the object
	libraryID     string    // Needed to download the file
} /rclone/rclone/blob/master/backend/seafile/webapi.go refers to download

    "last_modifier_name": "\u8d85\u7ba1",
    "uploader_email": "",
    "upload_time": "2018-07-11T05:14:20+08:00",
    "name": "",
    "permission": "rw",
    "uploader_name": "\u8d85\u7ba1",
    "uploader_contact_email": "",
    "last_modified": "2018-07-16T15:03:56+08:00",
    "mtime": 1531724636,
    "starred": false,
    "size": 2,
    "type": "file",
    "id": "86dd07538e51f8d437ecc25d9a48250041fef5a0",
    "last_modifier_email": "",
    "last_modifier_contact_email": ""

We can see there are the last_modified and mtime fields

Also rclone lsl returns the modification time:

/tmp/rclone-v1.54.1-linux-arm/rclone lsl seafile-foo:Notes/.sync
      482 2021-01-21 09:00:24.000000000 readme.txt
        1 2021-01-21 09:00:23.000000000 version.txt

Is it just a matter of adding some missing glue code somewhere? Am I missing something?

  • rclone-v1.54.1-linux-arm
  • Seafile community edition 7.1.5


PS: looks like I can't include links

Hi, welcome to the forum!

What the storage overview refers to, is the ability to set modification time, such that it can be used to later reliably compare timestamps of source and destination.

The cloud storage system supports setting modification times on objects. If it does then this enables a using the modification times as part of the sync. If not then only the size will be checked by default, though the MD5SUM can be checked with the --checksum flag.

All cloud storage systems support some kind of date on the object and these will be set when transferring from the cloud storage system.


If size is not enough to detect changes in your use case, the --checksum flag could be added. Though, Seafile does not support that either, it seems - it is listed without any hash algorithms in the overview.

In another thread it was mentioned that it is possible to use Seafile with Webdav and S3 backends, so perhaps you can make it work with either of these? You will not be able to access "files in an encrypted library" (Beta Testing: Seafile backend), so I don't know how that affects you..

This is right, the file details API does not return any checksum hash, or at least it wasn't until version 7.1 (which was the last time I had a deep look at the API calls).

Modtime will be set by Seafile to the last time you uploaded the file, but it cannot be set to the original time of the file you uploaded.

On a (almost) unrelated note, I always had issues syncing veracrypt files via the official Seafile client actually, very often it failed to see the file had changed.

1 Like

Thank you for the detailed feedback!

Regarding seafile through webdav I am already using that to sync notes from Joplin, and it is incredibly slow, so unfortunately I don't think that would be a good replacement. I'll try and keep you updated

Thank you for the initial Seafile backend btw :slight_smile:

I'll have a look at the latest API documentation about that.

For the Veracrypt containers, I was also facing this issue until I discovered a setting that updates the modification time on containers after use:

Preferences>Security>Filesystem>untick "Preserve modification timestamp of file containers"

Then the Seafile client will pick up changes as soon as the container file has been unmounted.

1 Like

Nice one! I'd never thought of that :roll_eyes:

You can use the --update flag on backends which don't support setting modtime

-u, --update Skip files that are newer on the destination.

Which generally does what you want.

Hello Nick,

Never tried that option, I confirm that for my use case (Seafile -> local sync), --update does the trick, thanks a lot!

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.