rclone
mount: respect --exclude filters while Offline uploading
Hi,
I have some files, that I don't want to be uploaded to the cloud. Instead, I want them leave local.
It would be nice, if offline uploading is respecting files or folders defined in --exclude-from, and leave them in the cache.
What I mean is related to the new parameter: cache-tmp-upload.
All files I create or copy/move on/to the mount, will be moved from the cache folder to the remote, after the defined cache-tmp-wait-time parameter.
It would be nice, if files or folders I specified in the --exclude-from file wont't get moved by the new cache-tmp-upload feature. I just want them to stay in the cache tmp folder.
So it's effectively something like what unionfs is doing. A combination of local files/folders and remote files/folders on the mount.
Hope it's clearer now.
I see what you mean. Why would you want that is my next question? Can you describe a use case?
e.g. I think it would be useful to avoid upload some tmp files that apps creates on the same path of the working file. You could "exclude" that tmp extensions, work with the mount path just like local HD, and will only upload saved docs, tmp files (files "excluded" will just live on local cache until deleted).
In my case the rclone mount is the data folder for my nextcloud installation.
Nextcloud generates thumbnail previews for each picture. For a quick loading of the images, I want them to load from local storage, instead from cloud.
Secondly there is also a log files which is constantly be written in the data folder. For this file, it also doesn't make sense to upload to the cloud.
Just to chime in here with another sample use case, Dropbox won't allow uploads of .DS_Store files (e.g. see this forum post or either of these two issues https://github.com/rclone/rclone/issues/287 / https://github.com/rclone/rclone/issues/280). It causes a situation where rclone is constantly trying to retry uploads for a bunch of files that will never succeed, far from ideal!
I see #2109 is being actively worked on, has much more discussion, and would satisfy this same use case.