Original files deleted after import without warning

[vixsomnis]

I think we should show a dialog for this. Someone might import a file, then delete the vault, and not realize they just erased their file.

Perhaps after import the user should be asked whether they want to delete the original?

[L-Henke]

:+1:

[vixsomnis]

I'll dig through the import code and find out where the files get deleted... To be continued.

[Graveen]

agree !

[L-Henke]

The AddFileJob starts the purging progress which first overwrites the file and then deletes it. https://github.com/SecrecySupportTeam/secrecy/blob/master/app/src/main/java/com/doplgangr/secrecy/jobs/AddFileJob.java#L51

We had a discussion about the overwriting of files in https://github.com/SecrecySupportTeam/secrecy/pull/133 if you care.

Edit: here: https://github.com/SecrecySupportTeam/secrecy/pull/133#discussion_r27768524

[vixsomnis]

I'll just try to put the dialog in there first. Then, maybe options to "just delete" and "attempt to purge". I think it's still useful to have the purging -- it just shouldn't happen by default.

[L-Henke]

I thing stating that files are purged just gives user a false security promise and thus is simply wrong. Telling them that it is tried to purge sound very weird to a user.. "Why is it just tried" etc. but thats not the point here.

In general we shouldn't add too much new features at the moment, instead we should focus on improving the code and fix open bugs. Also our support of the current android storage framework is pretty bad, because e.g. Samsung users can't use the sdcard and things might even get worse with M.

Adding simple dialogs is probably possible atm, but the real issues are elsewhere. If you are willing to fix some of these issues, just say so and I can give you more details.

[vixsomnis]

Deleting files without alerting the user is a pretty serious problem (worse than weird). I ended up nearly losing some files this way, but luckily I had a backup (and I didn't need encryption in the first place).

For the most part, I want to fix the things that annoy me, but I can take a look at other parts. I don't see any issues open for what you mentioned (this?).

In any case, it's hard to trust that the storage is done safely and correctly when stuff just doesn't work how you expect. It's not added features and bloat, just attention to detail. Secrecy needs some polish.

[Doplgangr]

@vixsomnis That's related to the external SDcard support we have been working on. The problem with Samsung is its inconsistent handling of external SD mountpoint, plus the lack of centralized API for storage which does not appear until KITKAT (Storage Access Framework)

What @L-Henke is stating is that we have just introduced storage access framework into our project which is quite immature, we still don't have much evidence to be confident with it. Thus we are feeling quite concerned whether things will work out in Android M.

[vixsomnis]

@L-Henke, send me some details (my email's in the commit log) or post some more issues, and I'll see if I can do anything about them.

@Doplgangr, I'll start reading up on the storage access framework and looking at how it's used here.

For now, I want to focus on user-visible changes since that's easier for me to test and debug. I'm still learning my way around the API.