I use icedrive.net for cloud storage. The service mounts as a drive letter rather than using a sync folder. It also supports end to end, zero knowledge encryption that shows up in the form of a folder on the mapped drive when a security key is entered. I am having some issues with Opus and only Opus when I try to copy or move files out of that Encrypted folder. It is only an issue with the encrypted folder and not any other folders stored on the service. I am able to copy the files just fine when using Windows explorer or Teracopy. Since the service just mounts as a drive letter I would expect this to work however once the files start to transfer maybe one file will copy and then the copy dialog just suddenly disappears. I'm hoping someone could help me figure out why this seems to only happen in Opus. I'm hoping that there are some logs I can provide and if it's not a setting I can tweak perhaps I'd at least have some information to go to Icedrive.net support with.Thanks!
Opus won't be treating that drive letter any differently to any other, in terms of how it opens files and reads data out of them during the copy process.
IceDrive is presumably indicating that the end of the file has been reached before it really has, or something like that.
You could try seeing what Process Monitor reports, but it's likely a problem on their side, not ours, which they'd need to investigate. Opus won't be treating their drive letter any differently to any other, so their filesystem emulation must not be entirely compatible.
If non-buffered I/O has been turned on in Opus (it's off by default), that can cause compatibility with some incomplete filesystems that don't support that I/O mode or haven't been tested properly with things that use it.
Thanks, it's just strange that I don't have any issues using the Windows explorer copy dialog or using Teracopy to copy the files. Are there any logs that I can look at in Opus that may help me debug?
Everyone tests their things with Explorer. If that didn't work, they wouldn't release them. But they don't tend to test their things with much else, and each program may work in a slightly different way. We've seen some strange behaviours over the years, including some filesystems/devices failing due to different buffer sizes, as well a the non-buffered I/O thing I mentioned, among other things. Or things like Google Drive crashing if you copied a desktop.ini file to it.
Logs of filesystem activity can be made using Process Monitor.
Thanks I'll look into that.
I looked into Icedrive a little bit more and it looks like they use Dokany to create their filesystem. I was wondering if there were any known issues with this project and DOpus that there may be a workaround for. @Leo I'm wondering if you have any familiarly with this or have seen a compatibility issue in the past that I can workaround. Otherwise for now I will use Teracopy when I have to copy files to/from that encrypted directory. Thanks!
It seems to have a lot of open compatibility issues and missing/broken functionality: Issues · dokan-dev/dokany · GitHub
Thanks, I opened a ticket with Icedrive support. Hopefully they fix this with a future update to their software. Until then I will workaround it. Thanks for your help!
As a workaround I implemented a button to open Windows explorer in the current directory. This way if I need to copy something to or from that folder I can easily click a button and open a regular explorer window. Things like this is exactly why I use DOpus, you can pretty much do whatever you want! Thank you for your help @Leo.
Hey @Leo I heard from IceDrive support. They were kind enough to test out DOpus and diagnose the problem. I'm wondering if based on their diagnosis there are any settings I can modify in DOpus to work around the compatibility issue. I'm quoting the response from IceDrive support. Thanks in advance for any help/input you may have!
Dear David,
We have done a little research on the subject.
Encrypted files are stored on Icedrive along with additional meta-information such as the size of the encrypted file. It is usually larger than the size of the decrypted file because the zero-knowledge encryption method we use adds some overhead.
When DirectoryOpus receives a list of files in a folder, it comes with the file sizes in an encrypted state, so when you copy a file from the cloud to your desktop, DOpus expects to get a larger file, but instead it gets a different size file. That's probably why copying doesn't work.
The following log data is an example of what happens when you try to copy the encrypted "file.txt" file to the desktop.
It is 80 bytes in the cloud and 40 bytes decrypted. The copy fails because (we assume) the listing data and the actual/decrypted data are different.fileInformation for file.txt: fileSize= 80 (encrypted)
ReadFile "\Encrypted\file.txt" offset 0 buflength 4096
downloading chunk 0 for file file.txt: range 0-4194303
Download request to "https://icecube-eu-279.icedrive.io/download"
fetch size: 80 bytes
decrypting chunk 0 for file "file.txt"
decrypting chunk... size = 48 ; padding = 8
chunk 0 decrypted, padding = 8 result size = 40
wrote 40 bytes with offset 0 to C:\Users\username\AppData\Local\Temp\Icedrive\4A786AB9.tmp
fully downloaded: "file.txt"
bytes to read: 4096, bytes read: 40, offset: 0
GetFileInformation: "\Encrypted\file.txt": filesize by handle for file "file.txt" : 40 (decrypted)Kind Regards,
Team Icedrive
@Leo I tested this myself, they are right. The file when it is in their Encrypted directory is larger than when it it moved out of the encrypted directory. Transfers from this directory work ok in Windows Explorer and Teracopy. I'm hoping there is some compatibility option I can change to allow Opus to move these files.
So their filesystem misreports file sizes? That’s broken by design in that case.
Look at how Windows handles compressed (or encrypted) files. The file size still reports the size of the full, uncompressed data. There is a separate “size on disk” statistic for how much space the compressed (or encrypted) data really takes up.
Their product has a design flaw if it works like that. It breaks the conventions of Windows filesystems, and will go wrong with more than just Opus.
That said, we will be adding an option to copy data via the Windows shell, so if that works with this it should also work in Opus in the future. But what they’re doing is still completely wrong. The size reported in a directory listing is the length of the data inside the file, not the amount of space it takes up (which is a separate attribute).
Thanks for the reply @Leo! You are completely right, after posting I discovered may of my "encrypted" files were corrupted. I subscribed to Icedrive to move a little further away from big tech but I think my best bet to is to just go back to OneDrive for stability reasons. I do appreciate all of your help and insight. Their product is definitely well intentioned but flawed in execution. As a side note it'll be great to have the option to copy using the windows shell at some point? Are you able to comment when that feature will be added?
Thanks again!
-David
I'm hesitant to guess in case it ends up being wildly wrong (which any guess I would've given before now would've turned out to be!).
No worries, thanks for all of your help!