Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

If one item of a copy fails, the copied .aze files cannot be decrypted ("Failed to decrypt")

Open
#4,754 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
android, kotlin
Domain
backend, mobile

Research direction

Start in app/src/main/java/com/amaze/filemanager/asynchronous/services/CopyService.java, around the failedFOps check at lines 273–284 on the referenced release/4.0 revision. Trace how successful copy and move operations are reported, then inspect findAndReplaceEncryptedEntry and related tests. Done means each successfully copied or moved .aze file has its encryption record updated even when another batch item fails.

Written by the indexing model from the issue text.

Description

Describe the bug
When .aze files are copied, Amaze adds an encryption record for each copy at its new path, but only if every item of the operation succeeded. If any one item of the batch fails, the .aze files that were copied successfully get no record. Tapping such a copy shows "Failed to decrypt" without asking for the password. The failure dialog names only the item that failed, so nothing hints that the .aze copy is affected.

To Reproduce
Steps to reproduce the behavior:

  1. In a folder, encrypt a file with the Amaze format (⋮ → Encrypt, tick "Use Amaze Encryption Format", password pw1) to get secret.txt.aze. In the same folder have a second file that the app cannot read, e.g. one owned by another app (here zz-locked.bin).
  2. Control: copy only secret.txt.aze to /sdcard/Documents and tap it there. The Decrypt password dialog appears.
  3. Select both secret.txt.aze and zz-locked.bin → Copy, open /sdcard/Download, PASTE.
  4. "Operation Unsuccessful – Operation failed for following files: 1. zz-locked.bin". secret.txt.aze was copied to Download (26 bytes, same as the source).
  5. Tap Download/secret.txt.aze: the toast "Failed to decrypt" appears and no password dialog is shown.

In explorer.db, the encrypted table had a row for /storage/emulated/0/Documents/secret.txt.aze after step 2, but no row for /storage/emulated/0/Download/secret.txt.aze after step 3.

Expected behavior
Every .aze file that was copied (or moved) successfully gets its encryption record at the new path, whether or not other items in the same batch failed.

Screenshots

Copy with an unreadable file Copied .aze file Control: copy alone
Only unreadable file reported Copied aze failed to decrypt Single copy asks for password
Copying secret.txt.aze together with an unreadable file: only zz-locked.bin is reported as failed. Tapping the copied Download/secret.txt.aze: "Failed to decrypt", no password dialog. Control: after copying secret.txt.aze alone, the copy asks for the password.

Smartphone (please complete the following information):

  • Device: pixel
  • OS: Android 11 (API 30)
  • Rooted: No
  • Version: 3.11.4

Additional context
Code on the default branch release/4.0 (94afab3): in CopyService, the loop that adds/updates the encrypted entries runs only if copy.failedFOps.size() == 0 (CopyService.java#L273-L284):

if (copy.failedFOps.size() == 0) {
  // adding/updating new encrypted db entry if any encrypted file was copied/moved
  for (HybridFileParcelable sourceFile : sourceFiles) {
    try {
      findAndReplaceEncryptedEntry(sourceFile);

The same block also handles moves that go through CopyService, so a partially failed move probably leaves the moved .aze files with their records at the old path. I only tested a copy.

Related: #4730 (same kind of problem: the encryption record is lost when an .aze file goes through the Trash Bin).

Dominant language
Kotlin
Stars
6.4k
Forks
1.7k
Avg merge
3d 17h
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TeamAmaze/AmazeFileManager

All issues in TeamAmaze/AmazeFileManager

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.