no-mimetype option unknown

[Ultome]

I would love to use your program, but after following the readme and running the script I get this result. Any idea how to fix this?

[Jwink3101]

Based on the changelog, that flag was added for 1.51.0 on 2020-02-01 so 1.45, doesn't support that flag.

The flag isn't strictly needed in the code but it is good to have since some remotes cost more calls to get mimetype and syncrclone doesn't use it

Since 1.45 is 2 years, 5 months, and 23 days old, I think it is worth upgrading to the newest!

Try that and let me know if it works for you.

Good luck! Also, please let me know what you think of the tool! I am curious how hard it is to set up since it is hard for me to judge how it would be for others

[Ultome]

Hey! Thanks for the follow up. Noob question, but since I followed the readme for installation, how to I get newer versions? How do I upgrade? Sorry for not being able to find out on my own ^^'

[Jwink3101]

I should have been more clear. You need to update your version of rclone, not of syncrclone (though it is good to make sure you're also running the latest).

It all depends on how you have it set up but I'd follow the rclone instructions here.

Alternatively, you can download the rclone executable here and then specify where you put the extracted version with the rclone_exe option

[Ultome]

Hello,

Here is the result I get now that I have updated rclone :

2021-05-18 20:33:16: syncrclone (20210419.0.BETA)
2021-05-18 20:33:16: config path: 'config.py'
2021-05-18 20:33:16: A: '/home/tome/Test'
2021-05-18 20:33:16: B: 'nextCloud:Test'
2021-05-18 20:33:16: rclone version:
2021-05-18 20:33:16: rclone: rclone v1.55.1
2021-05-18 20:33:16: rclone: - os/type: linux
2021-05-18 20:33:16: rclone: - os/arch: amd64
2021-05-18 20:33:16: rclone: - go/version: go1.16.3
2021-05-18 20:33:16: rclone: - go/linking: static
2021-05-18 20:33:16: rclone: - go/tags: none
2021-05-18 20:33:16: 
2021-05-18 20:33:16: Refreshing file list on A '/home/tome/Test'
2021-05-18 20:33:16: 1 files, 0.00 b
2021-05-18 20:33:16: Refreshing file list on B 'nextCloud:Test'
2021-05-18 20:34:57: 0 files, 0.00 b
2021-05-18 20:34:57: 
2021-05-18 20:34:57: Setting lock on A
2021-05-18 20:34:57: rclone: INFO  : LOCK_wr6ZwpTvxTs9: Copied (new)
2021-05-18 20:34:57: rclone: INFO  :         17 / 17 Bytes, 100%, 461 Bytes/s, ETA 0s
2021-05-18 20:34:57: 
2021-05-18 20:34:57: Setting lock on B
2021-05-18 20:35:57: rclone: INFO  :          0 / 17 Bytes, 0%, 0 Bytes/s, ETA -
2021-05-18 20:36:57: rclone: INFO  :          0 / 17 Bytes, 0%, 0 Bytes/s, ETA -

The program loads for a long time refreshing B, and then loops forever on the last line. Any idea? (btw I'm doing this hoping your script will allow me to sync 380,000 files totalling 10GB in less than 8 minutes, which is what I get with nextcloudcmd for now, do you think it will be possible?)

[Jwink3101]

hmm.

The simplest thing to do would be to disable locking...but I suspect that'll kick the can down the road since it is likely an issue with writing files to your remote.

Try the following

• Disable locking (it's in the config)
• Run with --debug and see what you get there (with and without locking)

• OUTSIDE of syncrclone, can you check if transfers a single file? Something like:

  $ echo "testfile1" > /home/tome/Test/test.txt $ rclone copyto -v /home/tome/Test/test.txt nextCloud:Test/test1.txt $ rclone copy -v nextCloud:Test/test1.txt /home/tome/Test/

  and then make sure that test.txt and test1.txt are the same?

That last check is really important as it is seeing what is happening and if it working to do the actual copies.

It is possible also that there is a bug in syncrclone with empty remotes but I think that is covered in the test suite.

[Ultome]

Even with locking disabled I get the same result. I have no problem transferring files without syncrclone. The --debug mode did not bring more light.

[Jwink3101]

I don't understand how you have the same result with locking disabled since it was stuck on setting the lock?

Anyway, I think we've moved beyond this GitHub issue and should move this to its own issue.

When you do, please post the full debug result with anything sensitive removed.

Also, I think I forgot to answer your other question.

By and large, the slowest part tends to be file listing. So depending on how long that takes, it may or may not match your performance requirements.

[Ultome]

Hello,

I don't know if you will get this email. But if you do, I would like to thank you for this amazing tool: I don't know what went wrong last time with NextCloud, but I'm using it with Google Drive this time and it works like a charm. Yay!

Thank you again!

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, May 19th, 2021 at 14:13, Justin Winokur @.***> wrote:

Closed #3.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.