S3Drive - Share links and file dates

Good morning! This is using Backblaze B2 with both the Windows app and the Android app. I'll start with the quickest one first: how do I see a list of links I have generated? I've looked around and cannot seem to find them. Second: is it possible to upload files and not have the date/time changed on them? Third I am having issues with share links. Doesn't matter whether they are created in the Android app or in the Windows app, they all do the same thing. A couple days ago I tried and realized I had to update my CORS rules, once I got all that figured out share links worked a couple of times so I thought everything was good. Now though, even though I do not know what changed, they are not. I generate a share then try to go to it in a browser and I can see the file in the web app although there is no thumbnail. Trying to download the file results in the Invalid Key IV error although the files have not been modified at all. I remember the other day at the end of the share link there was a "Key=" with a long string of characters after it but now there isn't. I have a couple of screen captures for you. Thanks!

Hi,

how do I see a list of links I have generated?

For managed accounts, these are available in the Links section of the Drawer menu. In your case, that is external S3/Backblaze, as such there isn't any registry of generated links, as links are self-signed and they're not stored anywhere on the S3Drive side, nor Backblaze. The indication that link was generated, is existence of the .aashare/<shareId> folder (please see attached screenshots). If you delete that folder, the "album" with file or files will be deleted which will render the shared link not working, however technically speaking, the "links" to each individual files within the album won't stop working until they expire (7 days at max). In the future we may improve that functionality, to keep track in app what links were generated and allow easier "revoke", auto-update etc.

9:13 AM

is it possible to upload files and not have the date/time changed on them?

The way the S3 protocol works, is that every time file is created/modified it stores the operation time. In order to preserve the file modification time, we use mtime header, which is compliant with the Rclone way of doing things. That means, that if you use Sync functionality between local (e.g. your filesystem) and remote (e.g. Backblaze), S3Drive will preserve file modification date. On the listings unfortunately we'll need to display the "last operation time" instead, as mtime isn't available without additional HEAD request, which would be slow/expensive to execute. Within each LIST request we get 1000 files, if we wanted to display real mtime, we would need issue additional 1000 HEAD requests which isn't feasible. On our managed S3 storage plans: https://s3drive.app/pricing?q=storage we have better control over the protocol and we will in the future return either mtime if it exists or last operation time if mtime isn't present. I hope that explains the internals.

9:14 AM

Trying to download the file results in the Invalid Key IV error

There was an issue in our Web client, which was failing to "obtain" the decryption key from the link, which is now fixed, so preview and download should work fine (even for pre-existing links).

although the files have not been modified at all.

That's useful to know, because if they were, then encrypted share would in fact stop working (due to different file encryption keys) until it's regenerated (doesn't happen automatically right now)

I remember the other day at the end of the share link there was a "Key=" with a long string of characters after it but now there isn't.

Encryption key is present after # in the link. Something like this: https://web.s3drive.app/s/<longBase64Characters>#9iFeqU0P9OmtLwH2OnEC2RJwyaV58dAKgVASYhCJg_o=

I can see the file in the web app although there is no thumbnail.

This is something we need to address for the files encrypted with the V2 encryption scheme. Basically we need to also pass the encryption keys for thumbnail in order to render it. Before this is done, we could actually "convince" web client to generate thumbnail from the full resource, but we've disabled that, as it was resource intensive in the browser. It seems that instead of "no thumbnail" icon, there is a "broken thumbnail" icon displayed. We'll see if that's something we can address promptly or if it have to wait little bit longer. In principle we plan to support thumbnails for the encrypted V2 share resources and we plan to support "updating" files in the existing resources (that is encryption key regeneration for the share). These things will come in the future.