You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ah, so I guess you are saying that if you use `--immutable when you are copying a single file then it is ignored?
Eg
$ mkdir src dst
$ echo hello > src/file2.txt
$ rclone sync src/ dst/
$ echo alskdjflksdjflsakdjf > src/file2.txt
$ rclone sync -vv --retries 1 --immutable src/ dst/
2021/01/15 14:31:03 DEBUG : rclone: Version "v1.54.0-beta.5062.236aa5a70.fix-4929-union" starting with parameters ["rclone" "sync" "-vv" "--retries" "1" "--immutable" "src/" "dst/"]
2021/01/15 14:31:03 DEBUG : Creating backend with remote "src/"
2021/01/15 14:31:03 DEBUG : Using config file from "/home/ncw/.rclone.conf"
2021/01/15 14:31:03 DEBUG : fs cache: renaming cache item "src/" to be canonical "/tmp/src"
2021/01/15 14:31:03 DEBUG : Creating backend with remote "dst/"
2021/01/15 14:31:03 DEBUG : fs cache: renaming cache item "dst/" to be canonical "/tmp/dst"
2021/01/15 14:31:03 DEBUG : Local file system at /tmp/dst: Waiting for checks to finish
2021/01/15 14:31:03 DEBUG : file2.txt: Sizes differ (src 21 vs dst 6)
2021/01/15 14:31:03 ERROR : file2.txt: Source and destination exist but do not match: immutable file modified
2021/01/15 14:31:03 DEBUG : Local file system at /tmp/dst: Waiting for transfers to finish
2021/01/15 14:31:03 ERROR : Local file system at /tmp/dst: not deleting files as there were IO errors
2021/01/15 14:31:03 ERROR : Local file system at /tmp/dst: not deleting directories as there were IO errors
2021/01/15 14:31:03 ERROR : Can't retry any of the errors - not attempting retries
2021/01/15 14:31:03 INFO :
Transferred: 0 / 0 Bytes, -, 0 Bytes/s, ETA -
Errors: 1 (no need to retry)
Checks: 1 / 1, 100%
Elapsed time: 0.0s
2021/01/15 14:31:03 DEBUG : 2 go routines active
2021/01/15 14:31:03 Failed to sync: immutable file modified
However this causes a problem
$ rclone sync -vv --retries 1 --immutable src/file2.txt dst/
2021/01/15 14:31:10 DEBUG : rclone: Version "v1.54.0-beta.5062.236aa5a70.fix-4929-union" starting with parameters ["rclone" "sync" "-vv" "--retries" "1" "--immutable" "src/file2.txt" "dst/"]
2021/01/15 14:31:10 DEBUG : Creating backend with remote "src/file2.txt"
2021/01/15 14:31:10 DEBUG : Using config file from "/home/ncw/.rclone.conf"
2021/01/15 14:31:10 DEBUG : fs cache: adding new entry for parent of "src/file2.txt", "/tmp/src"
2021/01/15 14:31:10 DEBUG : Creating backend with remote "dst/"
2021/01/15 14:31:10 DEBUG : fs cache: renaming cache item "dst/" to be canonical "/tmp/dst"
2021/01/15 14:31:10 DEBUG : file2.txt: Sizes differ (src 21 vs dst 6)
2021/01/15 14:31:10 DEBUG : file2.txt: MD5 = 703540df67ebbec009f8500dfca7c665 OK
2021/01/15 14:31:10 INFO : file2.txt: Copied (replaced existing)
2021/01/15 14:31:10 INFO :
Transferred: 21 / 21 Bytes, 100%, 81.904 kBytes/s, ETA 0s
Transferred: 1 / 1, 100%
Elapsed time: 0.0s
2021/01/15 14:31:10 DEBUG : 3 go routines active
Is that what you mean, or do you have other scenarios in which it goes wrong?
The immutable checking should probably be done in operations.Copy I suspect - that would mean that the checking would work everywhere.
I've been running into the same issue: The --immutable flag only works when moving directories to the remote. If you try to move a single file to the remote, the --immutable flag has no effect and the remote file gets overwritten.
I had been planning to use --immutable for backups as suggested by the docs which say that the --immutable flag "can be useful as an additional layer of protection for immutable or append-only data sets (notably backup archives), where modification implies corruption and should not be propagated."
This probably got lost with everything else going on, but figured i would comment anyways.
Current rclone version is 1.63.1 as of the time i'm writing, and this is still an issue.
I was testing s3 and used a filepath as src instead of a directory.
It overwrote my test file in s3 when using the --immutable flag, which i thought should not be possible, so then googled and came across this issue.
So warning to anyone else: Be careful thinking you are safe when using --immutable.
Still only works on dir and not files.
I have a verified workaround for this issue. Verified in that I used this very method (with some additional unrelated options to speed the transfer) to move 50 TB of data in only a few days between S3 buckets.
Create a text file and put the list of files you want to transfer in it. In my example, I will call it files.txt.
Run rclone to copy/move the files and then use the --files-from directive along with the --no-traverse directive.
While I don't pretend to know the code behind this, I do have a theory that the --immutable flag works here because it's still being treated as a directory operation, but with a filter vs an explicit single-object operation.
Activity
ncw commentedon Jan 15, 2021
Ah, so I guess you are saying that if you use `--immutable when you are copying a single file then it is ignored?
Eg
However this causes a problem
Is that what you mean, or do you have other scenarios in which it goes wrong?
The immutable checking should probably be done in
operations.CopyI suspect - that would mean that the checking would work everywhere.mmatczuk commentedon Jan 18, 2021
That is correct @ncw.
andrewdbate commentedon Oct 20, 2021
I've been running into the same issue: The
--immutableflag only works when moving directories to the remote. If you try to move a single file to the remote, the--immutableflag has no effect and the remote file gets overwritten.I had been planning to use
--immutablefor backups as suggested by the docs which say that the--immutableflag "can be useful as an additional layer of protection for immutable or append-only data sets (notably backup archives), where modification implies corruption and should not be propagated."ninthwalker commentedon Aug 9, 2023
This probably got lost with everything else going on, but figured i would comment anyways.
Current rclone version is 1.63.1 as of the time i'm writing, and this is still an issue.
I was testing s3 and used a filepath as src instead of a directory.
It overwrote my test file in s3 when using the --immutable flag, which i thought should not be possible, so then googled and came across this issue.
So warning to anyone else: Be careful thinking you are safe when using --immutable.
Still only works on dir and not files.
ncw commentedon Aug 9, 2023
This would be relatively easy to fix of someone wants to have a go. I can provide a roadmap of what needs to be fixed.
chris-zenfolio commentedon Feb 23, 2024
I have a verified workaround for this issue. Verified in that I used this very method (with some additional unrelated options to speed the transfer) to move 50 TB of data in only a few days between S3 buckets.
Example Code:
While I don't pretend to know the code behind this, I do have a theory that the
--immutableflag works here because it's still being treated as a directory operation, but with a filter vs an explicit single-object operation.fix(IDX): Don't overwrite CDN artifacts
fix(IDX): Don't overwrite CDN artifacts
fix(IDX): Don't overwrite CDN artifacts
fix(IDX): Don't overwrite CDN artifacts (#5438)
fix(IDX): Don't overwrite CDN artifacts (#5438)
fix(ci): upload CDN artifacts under their bundle (intended) name (#10672
operations: make --immutable work with copyto, moveto and single file…
operations: make --immutable work with copyto, moveto and single file…
ncw commentedon Sep 21, 2026
I've merged @hsdfat fix for this to master now which means it will be in the latest beta in 15-30 minutes and released in v1.76
operations: make --immutable work with copyto, moveto and single file…
operations: make --immutable work with copyto, moveto and single file…