Many tasks.
先搞定挂载好了。
国内社区基本没讲怎么挂载Google Drive。。。。
so干脆官网看看去了。
（顺便看到一个OneDrive 5T随便领的地方https://od.obagg.com/
Astonishing@mail.anandaigueschools.org
ndwqq412
上面那个5T随便玩，https://www.office.com/login登陆地址，onedrive不被墙LoL, 并且上面的账号可以使用office全套365，再也不用
Installing on Windows
To run rclone mount on Windows, you will need to download and install WinFsp.
WinFsp is an open source Windows File System Proxy which makes it easy to write user space file systems for Windows. It provides a FUSE emulation layer which rclone uses combination with cgofuse. Both of these packages are by Bill Zissimopoulos who was very helpful during the implementation of rclone mount for Windows.
Windows caveats
Note that drives created as Administrator are not visible by other accounts (including the account that was elevated as Administrator). So if you start a Windows drive from an Administrative Command Prompt and then try to access the same drive from Explorer (which does not run as Administrator), you will not be able to see the new drive.
The easiest way around this is to start the drive from a normal command prompt. It is also possible to start a drive from the SYSTEM account (using the WinFsp.Launcher infrastructure) which creates drives accessible for everyone on the system or alternatively using the nssm service manager.
Mount as a network drive
By default, rclone will mount the remote as a normal drive. However, you can also mount it as a Network Drive (or Network Share, as mentioned in some places)
Unlike other systems, Windows provides a different filesystem type for network drives. Windows and other programs treat the network drives and fixed/removable drives differently: In network drives, many I/O operations are optimized, as the high latency and low reliability (compared to a normal drive) of a network is expected.
Although many people prefer network shares to be mounted as normal system drives, this might cause some issues, such as programs not working as expected or freezes and errors while operating with the mounted remote in Windows Explorer. If you experience any of those, consider mounting rclone remotes as network shares, as Windows expects normal drives to be fast and reliable, while cloud storage is far from that. See also Limitations section below for more info
Add “—fuse-flag —VolumePrefix=\server\share” to your “mount” command, replacing “share” with any other name of your choice if you are mounting more than one remote. Otherwise, the mountpoints will conflict and your mounted filesystems will overlap.
Limitations
Without the use of “—vfs-cache-mode” this can only write files sequentially, it can only seek when reading. This means that many applications won’t work with their files on an rclone mount without “—vfs-cache-mode writes” or “—vfs-cache-mode full”. See the File Caching section for more info.
The bucket based remotes (eg Swift, S3, Google Compute Storage, B2, Hubic) do not support the concept of empty directories, so empty directories will have a tendency to disappear once they fall out of the directory cache.
Only supported on Linux, FreeBSD, OS X and Windows at the moment.
rclone mount vs rclone sync/copy
File systems expect things to be 100% reliable, whereas cloud storage systems are a long way from 100% reliable. The rclone sync/copy commands cope with this with lots of retries. However rclone mount can’t use retries in the same way without making local copies of the uploads. Look at the file caching for solutions to make mount more reliable.
Attribute caching
You can use the flag —attr-timeout to set the time the kernel caches the attributes (size, modification time etc) for directory entries.
The default is “1s” which caches files just long enough to avoid too many callbacks to rclone from the kernel.
In theory 0s should be the correct value for filesystems which can change outside the control of the kernel. However this causes quite a few problems such as rclone using too much memory, rclone not serving files to samba and excessive time listing directories.
The kernel can cache the info about a file for the time given by “—attr-timeout”. You may see corruption if the remote file changes length during this window. It will show up as either a truncated file or a file with garbage on the end. With “—attr-timeout 1s” this is very unlikely but not impossible. The higher you set “—attr-timeout” the more likely it is. The default setting of “1s” is the lowest setting which mitigates the problems above.
If you set it higher (‘10s’ or ‘1m’ say) then the kernel will call back to rclone less often making it more efficient, however there is more chance of the corruption issue above.
If files don’t change on the remote outside of the control of rclone then there is no chance of corruption.
This is the same as setting the attr_timeout option in mount.fuse.
简直无比麻烦，弄得我都想直接Raidrive了，不过感觉Raidrive比起rclone不是那么可靠。。闭源+只读不可写，除了UI好看点没什么卵用。。。
首先需要winfsp，然后写对命令就挂好了。
发现并没有那么简单，比如为了效率需要apply google API ID
Making your own client_id
When you use rclone with Google drive in its default configuration you are using rclone’s client_id. This is shared between all the rclone users. There is a global rate limit on the number of queries per second that each client_id can do set by Google. rclone already has a high quota and I will continue to make sure it is high enough by contacting Google.
It is strongly recommended to use your own client ID as the default rclone ID is heavily used. If you have multiple services running, it is recommended to use an API key for each service. The default Google quota is 10 transactions per second so it is recommended to stay under that number as if you use more than that, it will cause rclone to rate limit and make things slower.
Here is how to create your own Google Drive client ID for rclone:
- Log into the Google API Console with your Google account. It doesn’t matter what Google account you use. (It need not be the same account as the Google Drive you want to access)
- Select a project or create a new project.
- Under “ENABLE APIS AND SERVICES” search for “Drive”, and enable the “Google Drive API”.
- Click “Credentials” in the left-side panel (not “Create credentials”, which opens the wizard), then “Create credentials”
- If you already configured an “Oauth Consent Screen”, then skip to the next step; if not, click on “CONFIGURE CONSENT SCREEN” button (near the top right corner of the right panel), then select “External” and click on “CREATE”; on the next screen, enter an “Application name” (“rclone” is OK) then click on “Save” (all other data is optional). Click again on “Credentials” on the left panel to go back to the “Credentials” screen.
(PS: if you are a GSuite user, you could also select “Internal” instead of “External” above, but this has not been tested/documented so far).
- Click on the “+ CREATE CREDENTIALS” button at the top of the screen, then select “OAuth client ID”.
- Choose an application type of “Desktop app” if you using a Google account or “Other” if you using a GSuite account and click “Create”. (the default name is fine)
- It will show you a client ID and client secret. Use these values in rclone config to add a new remote or edit an existing remote.
Be aware that, due to the “enhanced security” recently introduced by Google, you are theoretically expected to “submit your app for verification” and then wait a few weeks(!) for their response; in practice, you can go right ahead and use the client ID and client secret with rclone, the only issue will be a very scary confirmation screen shown when you connect via your browser for rclone to be able to get its token-id (but as this only happens during the remote configuration, it’s not such a big deal)
starrydream@mail.oso.ac.cn
GJh2JQ35
留个备用的，虽然OneDrive挺垃圾的。。。
Due to the evil gov and relevant departments , I will transfer my steam account to another high-price country : Hong Kong , United States , Japan or UK.
(Decide to change to USA)
