[Features Request] Preserve file timestamps when encrypting/decrypting

[H-Sorkatti]

Hello there.

Thank you for the nice app.
I'd like to suggest 2 important modifications:

1- Maintain the original modification date of the files before they are encrypted in the specified container.
Currently once you add (encrypt) the file into the container folder, its metadata is overwritten by the new creation date.

2- Execute long running operations like mounting/encryption/decryption as foreground services.
Some android phones manufacturers have very aggressive battery optimization techniques running in the background. In my samsung phone, I cannot for example, leave DroidFS in the background while encrypting or decrypting a moderately large number of files, as it will most certainly be stopped. Setting the app battery usage as unrestricted did not help. Same can be said for mounting containers. If I send the app to the background, it would most certainly be dismounted after a while.

Thanks.

[hardcore-sushi]

Maintain the original modification date of the files before they are encrypted in the specified container.

Yes, this would be nice to have. I think it would still be better to let the user decide with a switch in the settings.

Execute long running operations like mounting/encryption/decryption as background services.

DroidFS already runs file encryption and decryption tasks in the background as a foreground service. I don't understand what you ask here.

Holding volumes open in a foreground service has already been proposed here: #250. It would also help implementing #73.

[H-Sorkatti]

Yes. #250 is exactly what I suffer from.

I also see that my wording was inaccurate, indeed I meant keeping a container open as a 'foreground' service with a persistent notification. Not a background service.

[hardcore-sushi]

v2.2.0 brings a new feature which, when enabled, should prevent any automatic interruption of file operations. Can you please check if it actually solves this issue?

[amirs444]

-> Here's another reminder to give a setting in Droidfs to preserve timestamps of the documents.

Thank you for the amazing app. You can market a paid & special version of droidfs for journalists and other people with special jobs, where the data cannot be forcefully taken by torturing the person into giving passwords.

[H-Sorkatti]

v2.2.0 brings a new feature which, when enabled, should prevent any automatic interruption of file operations. Can you please check if it actually solves this issue?

Can confirm interruptions of encryption/decryption operations stopped. Thanks.

Still waiting for preserving file timestamps feature.

[hardcore-sushi]

Here's another reminder to give a setting in Droidfs to preserve timestamps of the documents.

It's already marked as a feature request. Please be patient, open a PR, or fund the development.

You can market a paid & special version of droidfs for journalists and other people with special jobs, where the data cannot be forcefully taken by torturing the person into giving passwords.

How could the app help people being tortured not to disclose their password?

[amirs444]

open a PR

I type with two fingers and don't know anything about software programming. :-)

How could the app help people being tortured not to disclose their password?

I was reading a Reddit comment months ago that there is a special type of encryption which has two passwords, and two containers. And it is EXTREMELY difficult to find the two containers even in lab analysis. (I cannot believe how this is possible, but people on that Reddit post were very excited about it)

If the arrested person tells the second password, the kidnappers will only get access to the second container, which should only have "decoy" files and folders. And the remaining data is sent and corrupted into the free space of the disk.

The journalist can only be threatened with further torture if the second container or clues of a dual file system is detected. That encryption system somehow bypasses that.

Pardon me if I'm just wasting your time due to an old Reddit comment.

[H-Sorkatti]

How could the app help people being tortured not to disclose their password?

I was reading a Reddit comment months ago that there is a special type of encryption which has two passwords, and two containers. And it is EXTREMELY difficult to find the two containers even in lab analysis. (I cannot believe how this is possible, but people on that Reddit post were very excited about it)

It's a feature called hidden containers. It's available in veracrypt (desktop only).
Basically, you create a big file (container) that is encrypted and works as a virtual hard disk. Inside the encrypted container you can add another hidden container. And since the outer one is encrypted, nobody can prove there's a hidden container inside. It affords you "plausible deniability".

[hardcore-sushi]

OK I see. However, implementing this mechanism at the application level would be useless, as the attacker could bypass it by directly scanning the filesystem (with root access) to discover both containers.

Instead, it must be done at the data level. Shufflecake is an amazing project effectively bringing plausible deniability with up to 15 volumes hidden in a single large container. However, it doesn't expose filesystems but block devices. DroidFS support for shufflecake is already on the TODO list, but it would be extremely hard to implement rootless because of this.

If you like to discuss more about this topic, we should migrate to another thread in order to avoid polluting this issue.