Is streaming upload for google drive implemented?

Help and Support
1

Is streaming upload for google drive implemented?
And if it is not, if it will be in the future, will it be possible to download something, like torrents directly to mounted gdrive?
@ncw

2

Do you mean with rclone mount - it will be shortly…

rclone mount can cope with files which are written sequentially, but torrents are written out of sequence normally which means that they won’t work with rclone mount.

1 Like
3

Actually, the release version 1.37 also already has this – Google Drive’s Put was flexiable enough to upload files of unknown size. So feel free to use any version.

1 Like
4

I already tried it, it’s not the best way.
If you don’t provide a seedbox multi user: Ok, but with a seedbox multi-user, you will encounter the problem about permissions (chown), because when you do rclone mount command you do it with the current user (I assume you are root) then all folder/files are root:root.
You can specify uid:gid and permissions will be uid:gid you define with mount option.
You can add user to root group or you can have x mount for x users…

5

Not sure that’s accurate. Even standard linux cp operations fail when copying to gdrive rclone 1.37 mounts.

6

@ncw to clarify, on latest beta (v1.37-157-g5a3a56abβ) I’m observing the following on many ops.

2017/09/22 03:25:30 DEBUG : dir/: ReadDirAll:
2017/09/22 03:25:30 DEBUG : dir/: >ReadDirAll: item=6, err=<nil>
2017/09/22 03:25:30 DEBUG : dir/: Attr:
2017/09/22 03:25:30 DEBUG : dir/: >Attr: attr=valid=1m0s ino=0 size=0 mode=drwxr-xr-x, err=<nil>
2017/09/22 03:25:33 DEBUG : dir/somefile: Open: flags=OpenReadWrite
2017/09/22 03:25:33 DEBUG : dir/somefile: >Open: fh=<nil>, err=can't open for read and write simultaneously

Also:

2017/09/22 03:31:48 DEBUG : bar.txt (w): >Flush: err=<nil>
2017/09/22 03:31:48 DEBUG : bar.txt (w): Write: len=5, offset=4
2017/09/22 03:31:48 ERROR : bar.txt: WriteFileHandle.Write can't seek in file
2017/09/22 03:31:48 DEBUG : bar.txt (w): >Write: written=0, err=illegal seek
2017/09/22 03:31:48 DEBUG : bar.txt (w): Flush:
2017/09/22 03:31:48 DEBUG : bar.txt: WriteFileHandle.Flush ignoring flush on unwritten handle

Which yields something like Input/output error and write error: Illegal seek respectively on Linux.

I’m assuming the reason is that random writes and rw mode support are missing.
Not sure if you’re accepting donations, but I’d probably contribute to make those happen in the future.

7

Yes that is corrrect. That will require making a local copy of the file though as no cloud providers support random writes to the middle of files. It is on the road map, probably for 1.39

8

I think many use-cases would be solved with a write-back cache. In case of i.e. backup software or something like ENCFS, the ops performed are all within a window of time while the file is being processed. If the write-back cache had a “decay interval” of say 30s after the handle has been closed, then in many cases the file has already been processed and will not be touched again.

There aren’t many use-cases I can think of that would involve a true append operation (which would require the aforementioned download-write-upload operation).