Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow case sensitive local file rename #3593

Merged
merged 8 commits into from
Nov 17, 2022

Conversation

stevealexr
Copy link

@stevealexr stevealexr commented Oct 25, 2022

Description

The FAT filesystem in android sd card is case-insensitive. This allows case-sensitive renaming by checking whether the changed name and original name is equivalent case-insensitively and doing a double rename. Only the code for local file renaming is changed.
Not sure what indent to use.

Issue tracker

Fixes #3587

Automatic tests

  • Added test cases

Manual tests

  • Done

  • Device: Resizable

  • OS: Api 33

Build tasks success

Successfully running following tasks on local:

  • ./gradlew assembledebug
  • ./gradlew spotlessCheck
    These tasks failed even with unmodified source code so probably local configuration issues

@VishalNehra
Copy link
Member

VishalNehra commented Oct 25, 2022

Can you run ./gradlew spotlessCheck and apply suggestions to fix the build failure please?

newFile.setMode(OpenMode.ROOT);
a = !file.exists() && file1.exists();
}
errorCallBack.done(newFile, a);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need a fallback mechanism in case the second rename fails, fallback should attempt to rename back to original file name.

Copy link
Author

@stevealexr stevealexr Oct 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a simple check that attempt to rename back to original file name once, not sure if it is sufficient.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, changes seem fine. It would be a good practice to LOG.warn the inner else condition in case second rename fails.
Also, codacy does seem to complain can you fix the issue:

Check warning on line 673 in app/src/main/java/com/amaze/filemanager/filesystem/Operations.java

Codacy Production
/ Codacy Static Code Analysis
app/src/main/java/com/amaze/filemanager/filesystem/Operations.java#L673
These nested if statements could be combined

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a log message and combined those if statements.

@stevealexr
Copy link
Author

Can you run ./gradlew spotlessCheck and apply suggestions to fix the build failure please?

Managed to run spotlessCheck after applying this fix but assemble debug failure is caused by something else. I am using jdk 11.

@@ -441,6 +441,61 @@ public static void rename(

private final DataUtils dataUtils = DataUtils.getInstance();

private final Boolean isCaseSensitiveRename =
Copy link
Member

@EmmanuelMess EmmanuelMess Oct 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the case sensitive rename different? Shouldn't there just be filesystems that support case sensitive renames and filesystems that do not? And the renames be the same function?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach only cares about the value changed and not the type of filesystem. Although it does unnecessary double renaming in case-sensitive filesystem, it doesn't need to check the type of filesystem.

The 'localRename' function (can't think of a better name) is extracted from the original code to avoid code duplication.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the case sensitive rename different? Shouldn't there just be filesystems that support case sensitive renames and filesystems that do not? And the renames be the same function?

I think this should be okay as we know for sure most file systems that android supports doesn't support case sensitivity (exception ext4 in which case it needs to be kernel enabled). But I think it would make a marginal performance improvement if second part of the AND condition in this is used first.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I think it would make a marginal performance improvement if second part of the AND condition in this is used first.

I am more concerned on code legibility.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added comment on the purpose of isCaseSensitiveRename variable and refactored double rename part. Hopefully it is clearer.

@VishalNehra
Copy link
Member

Can you run ./gradlew spotlessCheck and apply suggestions to fix the build failure please?

Managed to run spotlessCheck after applying this fix but assemble debug failure is caused by something else. I am using jdk 11.

I think it's building just fine now remotely. For your local builds, I think you can point to your local jre instead. Make the following change in gradle.properties (if you're in mac).
org.gradle.java.home=/Applications/Android Studio.app/Contents/jre/Contents/Home

@@ -441,6 +441,74 @@ public static void rename(

private final DataUtils dataUtils = DataUtils.getInstance();

/**
* Determines whether double rename is required based on original and new file name regardless
* of the case-sensitivity of the filesystem
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This only depends on the case sensitivity of the filesystem.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I change it to a filesystem case-sensitivity check by checking whether both upper case and lower case input name for file exists return true.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new solution seem to be costly solution and calculating this each time is redundant. If a filesystem is case insensitive then it'll always be case insensitive, so you can persist the result of this in shared preferences and use that from next time.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are multiple local filesystems like sdcard storage and internal storage. The types of filesystem need to be stored with the mount points. Rolling back to previous solution seems easier.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure please revert back to your old solution. Also note that the new code will double rename even when FS is insensitive and new file and old file names aren't similar at all.
oldFile.getSimpleName().equalsIgnoreCase(newFile.getSimpleName())
&& !oldFile.getSimpleName().equals(newFile.getSimpleName());

Please also note that I've increased the bounty price for this issue to 10USD you can claim once this PR is merged from the linked issue.

VishalNehra
VishalNehra previously approved these changes Nov 17, 2022
@VishalNehra VishalNehra changed the base branch from release/4.0 to hotfix/3.8.3 November 17, 2022 20:08
@VishalNehra VishalNehra dismissed their stale review November 17, 2022 20:08

The base branch was changed.

@VishalNehra VishalNehra merged commit 62c53ab into TeamAmaze:hotfix/3.8.3 Nov 17, 2022
@VishalNehra
Copy link
Member

VishalNehra commented Nov 17, 2022

Please claim bounty here @stevealexr

@stevealexr
Copy link
Author

stevealexr commented Nov 18, 2022

Please claim bounty here @stevealexr

Screenshot 2022-11-18 093833

I can't submit the claim. No claim button. Possibly because it has been too long since I submit solve issue. I sent a message to their customer support. I have claimed it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Renaming and only changing case fails
4 participants