Retrieve the database file before unlocking about keepassdx HOT 8 OPEN

KeePassDX is slow to open the database from remote storage compared to Keepass2Android.

KeePassDX, unlike KeePass2Android is only the editor and not the file manager. It will never contain internet permissions and will never contain cloud APIs. #342

If it's slow to open, the file manager you're using isn't using a cache for the file provider. Ask the developers of the synchronization application you use to improve the concept.

Will be processed in FileSync.

from keepassdx.

In order for a KeePass editor to access the database it needs to do three things:

1. Obtain the contents of the file
2. Obtain the credentials for decryption
3. Decrypt the file

All I'm asking is for steps 1 and 2 to be performed in parallel. This isn't an issue for FileSync to resolve.

from keepassdx.

The contents of the file cannot be decrypted without having the credentials. And the decryption is done directly from the URI stream.
It can't be much improved in terms of duration at this level since KeePassDX only has access to the stream.

KeePassDX is slow to open the database from remote storage

You indicate a notion of files from remote storage, except these notions only exist in the file manager you use, not in KeePassDX which only sees the file provider exposed, so the stream of the file already available.

from keepassdx.

If it's slow to open, the file manager you're using isn't using a cache for the file provider.

That is just creating more opportunity to end up with additional versions of the file that need to be merged, which makes the problems described in #1525 occur more often.

(It pre-supposes that I use a file provider that can do this kind of synchronisation of the file in advance so that there's a up to date cached version. WebDAV doesn't have a means of update notification other than frequent polling which is undesirable over mobile data.)

The contents of the file cannot be decrypted without having the credentials. And the decryption is done directly from the URI stream. It can't be much improved in terms of duration at this level since KeePassDX only has access to the stream.

Open the file stream but leave the file seek position at the start. The file manager will start downloading the file before data is read from the stream.

from keepassdx.

You indicate a notion of files from remote storage, except these notions only exist in the file manager you use, not in KeePassDX which only sees the file provider exposed, so the stream of the file already available.

You're deliberately ignoring that many file providers are for remote storage. The request to retrieve the file before unlocking implicitly only applies to remote storage because files in local storage do not have an access time problem.

It is not helpful to only consider the use of your application in isolation, ignoring problems caused by the combination of it and other applications because of an arbitrary decision about which application should resolve the problem regardless of how impractical that is.

from keepassdx.

Open the file stream but leave the file seek position at the start. The file manager will start downloading the file before data is read from the stream.

Checking the URI metadata to show the file name and size does not allow to launch the background actions?
Because opening the file stream means starting the foreground service to open the database and put it on hold, it requires a lot of development. And to me it just looks like a workaround.

You're deliberately ignoring that many file providers are for remote storage.

Not really. I simply respect the file provider contract.

The request to retrieve the file before unlocking implicitly only applies to remote storage because files in local storage do not have an access time problem.

Yes, but checking the URI metadata should logically cause the file to be updated and the password page does access the metadata when the activity is opened. Then maybe there are bugs and KeePassDX doesn't update the changed metadata on this page but it shouldn't require opening the stream if the user don't tap the "open" button.

It is not helpful to only consider the use of your application in isolation, ignoring problems caused by the combination of it and other applications because of an arbitrary decision about which application should resolve the problem regardless of how impractical that is.

I am not ignoring the problems at all. I try to solve all bugs, if you make a pull request that solves the problem if it's in KeePassDX side, of course I will accept it. I can reopen the issue if that's what's bothering you.
I assume that each application has its own responsibility, and that it is not up to another application, which respects the official implementation, to propose workarounds for the application that proposes the data. That's why I want to do Filesync, after that it's a lack of time, not ignorance of problems...

from keepassdx.

Open the file stream but leave the file seek position at the start. The file manager will start downloading the file before data is read from the stream.

Checking the URI metadata to show the file name and size does not allow to launch the background actions?

There is nothing in ContentResolver.query (not used), DocumentFile.fromFile or DocumentFile.fromSingleUri that in any way implies this will refresh the metadata.

ContentResolver.refresh can be used to explicitly refresh the content, which should include the metadata.

There doesn't appear to be a fully specified API that describes how metadata, file versions or save conflicts should work.

The request to retrieve the file before unlocking implicitly only applies to remote storage because files in local storage do not have an access time problem.

Yes, but checking the URI metadata should logically cause the file to be updated

You're assuming the behaviour you want from the API you're calling when it's not documented as doing (or not doing) that.

I would probably assume the opposite from the DocumentFile APIs because an application could reasonably be expected to call it to read the metadata for hundreds of files. Accessing the network for every one of those would be inappropriate so at some point it must use already cached data.

If you make a pull request that solves the problem if it's in KeePassDX side, of course I will accept it.

You're not going to accept a change if it doesn't meet your constraints on the separate responsibilities of applications.

from keepassdx.

I assumed that the metadata could be updated simply because during testing it was possible to do so. That's even why the detection system for modified files works and offers the merge dialog.
The refresh seems to correspond exactly to what we want to implement.

I would probably assume the opposite from the DocumentFile APIs because an application could reasonably be expected to call it to read the metadata for hundreds of files. Accessing the network for every one of those would be inappropriate so at some point it must use already cached data.

You can assume the opposite but in reality it just depends on the application that implements the FileProvider. The use of a cache for a hundred files is feasible after that it depends on the strategy of this cache according to the file manager application that has set it up. If the file manager clearly indicates that the files they offer are only updated after a user action, I have no problem with that, the user will be aware of it. If there is no indication, I simply assumed that the information returned in the request is correct.
The access to the network and the uploading of files through this network corresponds to the strategy of the file manager application, but the data consumer doesn't really know this strategy sometimes and don't even know there is a cache and think there is one in KeePassDX (when there is not at all at this level). This is clearly a lack of documentation in the file managers.

So it is the documentation of the application that implements the SAF that indicates how the file provider behaves, that's just it. But in the majority of cases, cloud applications are opaque and do not indicate any clearly stated policy to the user. We need to change that with FileSync.

You're not going to accept a change if it doesn't meet your constraints on the separate responsibilities of applications.

Yes it makes sense, I explained it, that's why the application was created in the first place and that's what FileSync is designed for. Again, I'm not stopping anyone from using KeePass2Android, it's a good app, it just doesn't match the separation of concepts of KeePassDX.

from keepassdx.