Maybe someone could tell me what am I doing wrong.
In fact i am a pretty new Mac user, therefore decided to use TotalFinder to make my life and the transition a bit easier.
However with the totalfinder when I want to simple rename (simple enter on the file name) a file I am getting the subjected errorcode (43) and the name remains as it was plus can not open the file anymore, because I get a message “The application can not be found”.
I try to rename typically pdf files which are generated by scanner and I want to rename them based on their content.
Before Totalfinder I have never had such a problem.
Please quit TotalFinder and launch plain Finder.app and try it there.
To return to pain Finder, use CMD+OPT+ESC and Force Quit Finder.app. After that Finder restarts without TotalFinder.
I would guess you have broken association of PDF file extension with application to open it. During renaming, you accidentally executed “open” action and that failed because of broken link. My theory.
I just have installed Adobe Reader and it seems the renaming works well in TotalFinder.
Till now it was not necessary to have the Adobe, as I could see everything in the mac preview, also now with Adobe installed the pdfs are opened in the mac preview which is fine for me.
I have the exact same symptoms like the OP. Those seem to be introduced in recent versions, cause it worked before. I am currently on 1.5.15.
I can reproduce the issue like follows:
CMD+I on a file on a drive nested in one or more folders. It shows the place of that file as:
/Volumes/Drive/folder/file
when I unmount and remount the drive and do the same again, I see:
/folder/file
When TotalFinder is in that situation, I cannot rename or open that file. Also when dragging that file into Terminal.app the path is wrong.
When I restart Finder and TotalFinder everything works normally again.
@marc have you tried it with plain Finder as well?
I’m trying to reproduce it under 10.9.2 with some DMG files. For me it works just fine. What is the underlying filesystem you are mounting? Do you use macfuse or something similar? To me it sounds like an issue of that underlying system.
Can you describe in more detail what do you exactly do?
I unmount and remount an internal HDD. I have a MacBook Pro with SSD as system drive and an HDD placed where before an optical drive used to be.
I will try to reproduce it via a different way, like DMG or external HDD. So far I recognized it only with my internal HDD, since I unmount und remount that drive regularly. I will report here, if I found an alternative method to reproduce it. I will also give more details on how I actually unmount and remount, after my search for alternative methods, today.
Sorry, I just tested with plain Finder and no TotalFinder processes running. And I could reproduce it there too! I will investigate further with guest account and check my kernel extensions and stuff. This is really ugly.
I tested now under mac os x guest user. Freshly logged in the issue did not appear with plain finder. Then I started TotalFinder.
I could reproduce the issue with TotalFinder running.
Then after killing Finder and TotalFinder I retried with plain Finder. The issue still could be reproduced.
Then I killed -9 Finder. After that plain Finder was fixed. I could not reproduce the issue with plain Finder. I will test more and hopefully can give a really detailed step by step description in my next post, so you finally can reproduce the issue too.
The issue is really crazy. And atm I am not very sure it is the fault of TotalFinder. Although with the help of TotalFinder it is easier for me to reproduce. But meanwhile I also can reproduce it with plain Finder.
However I found the issue, is restricted to one folder ‘/data’ on that HDD. I can rename it with terminal and create a new empty folder ‘data’ and move the content over to the new folder ‘data’.
What is crazy, the issue will come back after some restarts of Finder only for the folder ‘data’. Sibling folders of ‘/data’ lets say ‘/test’ with some file in it “/test/foo.txt” do not have the issue.
I am still searching, what might be the cause. My current try is reindexing spotlight.
I have done so far:
disk check with /Applications/Utilities/Disk\ Utility.app
Ok I nailed it down:
As I mentioned before it seemed to be related to that folder ‘/data’. I did a binary search by moving around folders and subfolders and so realized that a certain subfolder ‘/Volumes/FMB/data/marc/Movies/x/mov/cool_movie/’ was the only folder needed to reproduce the issue. I then remembered that this folder was a shared folder for local networking. I disabled sharing of that folder and the issue was gone. I enabled sharing it and the issue was present again.
Finally I was able to reproduce the issue with a dmg and a newly created folder in that dmg:
Here is the test. For effective reproducibility I tried to put the steps into command line.
TIP: Copy/paste into a text editor that has line wrapping disabled.
TIP2: Manually closing the info window can be omitted, cause its done automatically on unmount.
# in Terminal.app:
# prepare dmg ...
hdiutil create -size 10m /tmp/Test.dmg -ov -volname "Test" -fs HFS+
open /tmp/Test.dmg ; sleep 3
mkdir -p /Volumes/Test/foo/bar/baz
touch /Volumes/Test/foo/bar/baz/qux.txt
# Now begin testing step by step, comments (#) contain instructions ...
sudocmd= ; $sudocmd echo start test $sudocmd ; diskutil unmount Test; sleep 3 ; $sudocmd echo some command with or without sudo ; diskutil mount Test; osascript -e 'set macpath to POSIX file "/Volumes/Test/foo/bar/baz" as alias' -e 'tell application "Finder" to open information window of macpath'
# in info window: verify place (Where:) is '/Volumes/Test/foo/bar' ---> This is how it should be, everything looks correct.
# close info window
# repeat several times: last terminal command line (KEY UP in Terminal.app), in info window verify place (Where:), close info window
# share folder '/Volumes/Test/foo/bar/baz' with next steps ...
# open info window with the last terminal command line (KEY UP in Terminal.app)
# check (enable) 'Shared folder'
# close info window
# repeat last terminal command line (hit KEY UP in Terminal.app)
# in info window: verify place (Where:) is now '/foo/bar' ---> This is the issue. It's simply wrong and causes problems in many Finder operations: opening files, renaming, copying, moving, applying .DS_Store, dropping item to Terminal.app, ...
# close info window
# repeat several times: last terminal command line (hit KEY UP in Terminal.app), in info window verify place (Where:) is now '/foo/bar', close info window
# really crazy: modify the command line, set sudocmd=sudo ...
# NOTE: we are only echoing with sudo, the other commands are run as user
sudocmd=sudo ; $sudocmd echo start test $sudocmd ; diskutil unmount Test; sleep 3 ; $sudocmd echo some command with or without sudo ; diskutil mount Test; osascript -e 'set macpath to POSIX file "/Volumes/Test/foo/bar/baz" as alias' -e 'tell application "Finder" to open information window of macpath'
# in info window: verify place (Where:) is '/Volumes/Test/foo/bar' ---> WTF!!! It's fixed. Could this be my ugly workaround?
# close info window
# repeat several times: last terminal command line (sudo version) (KEY UP in Terminal.app), in info window verify place (Where:), close info window
# undo share folder and verify place again with next steps ...
# open info window with the last terminal command line (sudo version) (KEY UP in Terminal.app)
# uncheck (disable) 'Shared folder'
# close info window
# run first (non-sudo) terminal command line (hit KEY UP 2 times in Terminal.app):
sudocmd= ; $sudocmd echo start test $sudocmd ; diskutil unmount Test; sleep 3 ; $sudocmd echo some command with or without sudo ; diskutil mount Test; osascript -e 'set macpath to POSIX file "/Volumes/Test/foo/bar/baz" as alias' -e 'tell application "Finder" to open information window of macpath'
# in info window: verify place (Where:) is '/Volumes/Test/foo/bar' ---> If no shared folder is nested, then place (Where:) is correct.
# close info window
# repeat several times: last (non-sudo) terminal command line (KEY UP in Terminal.app), in info window verify place (Where:), close info window
The good news for TotalFinder is: this also happens with plain Finder. I would appreciate if you @darwin or anybody else could try to reproduce the test on a vanilla 10.9.2 or at least an installation w/o any trace of TotalFinder.
Ideas on how to deal with this issue are also welcome. Thx a lot.
Force quitting and relaunching the Finder can fix this issue easily. Finder probably encountered a bug which actually prevented it from deleting a file properly but Mac only produced the Error Code -43 without trying to find a solution.
or Unlocked the folder, following this steps
here: https://www.errorsolutions.tech/error/error-code-43-mac/
Solution 3. Unlock Folder
I will investigate further with guest account and check my kernel extensions and stuff. This is really ugly.