GitFinder mishandling files with special characters in the filename

[asegner]

1. Go into a monitored folder with a green check mark
2. Run mkdir test_sp test_base
3. Run touch test_base/muller.txt
4. Run touch test_sp/müller.txt
5. git add .
6. git commit -m "test"
7. open finder window with parent displaying both test_sp and test_base
8. highlight both folders and move to trash
9. observe test_sp folder going into a constant loop reappearing and disappearing while test_base behaves as expected

[milke]

I didn't manage to reproduce exactly your case, but I managed to see some other anomalies when having this müller.txt file… Strange, since I've never noticed any problem with files with special characters before, nor has anyone reported it before as well (and I know a lot of copies were sold in Japan).

Anyway, I'll investigate what's going on here and try to fix it as soon as possible.

[milke]

I've just released a new beta version 1.7.9b1 (130). You can download it here, but you can also upgrade your current version using Preferences > Updates, just make sure to check Beta update channel.

This version fixes issues with files with special characters in filenames (and some other issues as well, you can check release notes during the upgrade). So please, give it a try. I tested it quite thoroughly, but some things I still want to test more. And it always may be that I missed something, so I'd be thankful if you update and use it for a week or so and tell me if you encounter any problem again.

[asegner]

I have upgraded however i still see an issue when running the test case above in my repository.

The following file is constantly appearing and disappearing inside test_sp "müller.txt ?.gitFinderDeleted"

It also causes higher than expected cpu usage for GitFinder. The issue occurs as long as the changes are unstaged or staged. The issue stops when I commit the changes.

[asegner]

Here tree was run back to back and you can see the file disappear.

master ● › [0] % tree untitled\ folder untitled folder ├── test_base │   └── muller.txt \016.gitFinderDeleted └── test_sp └── müller.txt \016.gitFinderDeleted

3 directories, 2 files

master ● › [0] % tree untitled\ folder untitled folder ├── test_base │   └── muller.txt \016.gitFinderDeleted └── test_sp

3 directories, 1 file

master ● › [0] % git status On branch master Your branch is up to date with 'origin/master'.

Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) deleted: untitled folder/test_base/muller.txt deleted: "untitled folder/test_sp/m\303\274ller.txt"

no changes added to commit (use "git add" and/or "git commit -a")

[milke]

• Regarding those .gitFinderDeleted files, you may want to know why they appear and what they represent. So please, read #23 and #38 . They explain the history of the feature and how it involved during time to avoid certain problems. I know it's a bit longer read, but I believe it's worth it.

• Previous buggy version, due to incorrect handling of some non-ASCII characters in precomposed and decomposed C strings, put a repository into inconsistent state regarding its workdir and index.

• .gitFinderDeleted file(s) keep(s) appearing and disappearing (and that also increases CPU usage, as GitFinder constantly keeps on creating and deleting them like crazy) due to mentioned inconsistent state between repository's workdir and index, caused by previous buggy version.

• If you try the new beta version in the repository already screwed (inconsistent state) by the previous version, the new version cannot fix it. You can fix the repository from the command line (or some other git client), but if it's just a test repository, I suggest you to just trash it and forget it.

• That being said, I'd like to know if you still see the issue when trying some already screwed repository, or you see it as well on newly created repositories, or those you didn't screw with previous version of GitFinder.

• If your test case is creating a completely new repository and doing some operations on it (like you did in your initial post) and you still see the issue, please outline the steps I need to do to reproduce the problem.

• Besides other tests, I did the one from your initial post (in a new, freshly created repository) and everything works fine, .gitFinderDeleted files are created (with hidden extension) as they should, as a placeholders for git-deleted files (see linked issues in the first bullet of this list).

Thanks for your time and help with fixing this.

[asegner]

excellent - it does appear to be fixed on new repositories.

how would i fix a repo on the command line that is in this inconsistent state from prior versions?

[milke]

Great that it works. Please, use this version in the coming days and let me know if you encounter again problems with handling files with special characters in their names (or any other problem for what it matters).

Regarding "fixing" a repository, It really depends on what stage it is currently in. First off, be sure GitFinder isn't running, due to .gitFinderDeleted files creation. Then, try this:

git reset --hard

This should be enough in most cases. It should reset both the index and working tree. Note that it will also discard all uncommitted changes you've made in the meanwhile.

[asegner]

Reset seems to work! Thanks for all the help.

[milke]

Just to confirm… I've received an email about the message, which you apparently deleted…

Well i reset hard the repo on which I originally noticed the issue and reversed the couple test commits. The git status shows as clean

On branch master Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. (use "git pull" to update your local branch)

nothing to commit, working tree clean However, GitFinder is still showing changes in the folder for any file with a special character in the name. I tried cloning into a fresh folder and viewing the repo and i get the same thing.

So, git reset --hard (while GitFinder wasn't running) definitely did the trick?

[asegner]

Yes, i found this repo had another issue. It was created on a case-sensitive filesystem and i was checking out into a case-insensitive filesystem. After additionally correcting the conflicting filenames, all seems to be working now.