linerxchange.blogg.se - Cryptomator google drive all files

#Cryptomator google drive all files 64 bits#
#Cryptomator google drive all files windows#

I believe the uploaded data is often (if not always) collected by intelligence agencies.

The data can be potentially accessible by cloud provider’s employees.

The security of the cloud provider can be compromised and my data will leak.

A cloud is a convenient solution, however, I always felt remorse after putting my important data there for While I have never had any issues with the first two points, keeping the backup offsite was somehow problematic for me. If we talk about backups, there is also one another pretty wise rule: The 3-2-1 backup rule:ģ: Create one primary backup and two copies of your data.Ģ: Save your backups to two different types of media.ġ: Keep at least one backup file offsite. If I try to list the plain directory from the Cryptomator's virtual drive instead I have to wait again 4/5 secs.I guess we all know this saying and I guess all of us have already advanced from type 2 to type 1 a long ago:

#Cryptomator google drive all files windows#

If it can be useful, my cpu is an old and overclocked AMD f圆300, 16GB of ram and I'm using Windows 64bitĭisabling Google file stream's automatic sync didn't helped :/Īlso, if I try to list the encrypted directory from the Google's virtual drive, the listing occurs immediately. My setup is Cryptomator 1.5.5 (with Dokany, but I don't know its version :c) downloaded with the windows installer, opening a valut inside a Google file stream (v 39.0.10.0) virtual drive.Ĭryptomator uses less than 10% of cpu, Google file stream instead 20/30%.

With about 2.5k small (~1MB) files being copied into a folder, at the end I have each file taking 4/5 seconds of nothing before actually being copied. txt suffix.Įdit: Enhanced the script to fit better the issue description by adding second copy operation. Remark: For the upload the script needed to be renamed, ust remove the. Also the second copy operation is ok, if one computes the average time for a 4000 batch of the first Can you try this script first on a vault on the local Filesystem and in the second step on a vault on the Google shared drive? You only need to edit the $source and $vault variables. I'm not a filesystem specialist, but 3min and 35s seems reasonable for 20.000 files. Single copy operation execution times written to T:\mnt\opMass.log (bundled for the first and second copy batch) This script copies 20000 times a small logo to a directory in a Cryptomator volume mounted at T:\mnt, waits for 10 s and copies additionally 4000 times int the dir and deletes the directory afterwardsĬreating directory T:\mnt\testdir inside the vault.ĭownloading test image from to T:\cryptomator.png. Maybe if there was a way to cache the list of existing files or a switch we could temporarily disable this behavior? When I was going to attach logs I saw why this happens: before creating a file cryptomator tries to check if the file already exists and for that it lists every file, and because there are so many it takes time. But if the vault has a large number of files, copying a new file takes a looooong time to start. If the vault has a "small" number of files, copying a new file starts imediatly. I'm not talking about the delay required when first access to a folder.Įven after reading and writing files to a folder, if there are many files it takes a long time to start the process of writing a new file. Same delay when copying files even if there are lots files already in the vault.

Get desperate with big pauses between files.

Wait for the first thousands files to be copied.

#Cryptomator google drive all files 64 bits#

Operating system and version: Windows 10 64 bits with latest updates.I had to use -thread-count 5000 -timeout 100000 to reduce "insufficient resources" errors when accessing vault with lots of files.Īlso, despite the vault being created in a Google Shared Drive I don't think it's responsible for the delay because the files being copied are synchronized way before a new file starts to copy to the vault.Īlso doesn't matter if copying with windows explorer or robocopy command line tool. But each file takes a long time to start being copied. Note that once the file starts being copied it's a fast transfer. I separated my data in several vaults, but it's the second vault I needed to create in this conditions and takes more than 3 days to copy 25000 files (average of files is 2 MB) because there's a delay of almost half a minute before each file even with files of a few KB. First reading and listing the files in the vault (but that's expected) and then before every file it's being copied. When creating a vault with a large number of files (like more than 10,000), the first thousands of files are copied as fast as expected, but as the number of files in the vault grow there's a pause before each file (doesn't matter the size of the file) and that pause is increasing as the number of files in the vault increases.Įven if I restart the computer, when resuming copying takes a loooong time. (This is more a design problem than a bug, but very problematic.) Description