Directory path is weirdly truncated, makes "Copy Path" and "Reveal" not work...
Graphically shows disk usage for Macs
Brought to you by:
eriban
Menu
▾
▴
1 Attachments
#117 Directory path is weirdly truncated, makes "Copy Path" and "Reveal" not work correctly
I'm not sure when this issue started, but it occurred for me on 3.4.2 so I upgraded to 3.5.2 and the problem still exists, so I'm opening this ticket.
First, environment:
- iMac 27" 2020 w/ 3.6 GHz 10-Core Intel Core i9
- macOS Ventura 13.6.9
- GrandPerspective 3.4.2 & 3.5.2
Here's the output:
$ pwd
/Volumes/Alt-ExternalHD/Users/dossy/Work/Stuff_For_Your_Dog
$ /Applications/GrandPerspective.app/Contents/MacOS/GrandPerspective
2025-05-02 14:22:08.800 GrandPerspective[73431:77712058] +[CATransaction synchronize] called within transaction
2025-05-02 14:22:24.093 GrandPerspective[73431:77712083] fastPackageCheckEnabled = 1
2025-05-02 14:22:24.098 GrandPerspective[73431:77712083] Volume format = APFS (Encrypted)
2025-05-02 14:22:24.098 GrandPerspective[73431:77712083] fstypename = apfs
2025-05-02 14:22:24.098 GrandPerspective[73431:77712083] ignoreHardLinksForDirectories = 1
2025-05-02 14:22:24.099 GrandPerspective[73431:77712083] Scanning volume /Volumes/External [External], starting at rnalHD/Users/dossy/Work/Stuff_For_Your_Dog
2025-05-02 14:22:24.217 GrandPerspective[73431:77712083] Done scanning: 544 folders scanned (0 skipped) in 0.12s.
When I select a file in the output and try "Copy Path" it copies this:
/Volumes/External/rnalHD/Users/dossy/Work/Stuff_For_Your_Dog/2019/Logos/logo-1200x630.psd
And, if I try to "Reveal" that file, I get a modal error:
Failed to reveal the file "logo-1200x630.psd"
A possible reason is that it does not exist anymore
The issue appears to be a weird string truncation bug? Specifically:
2025-05-02 14:22:24.099 GrandPerspective[73431:77712083] Scanning volume /Volumes/External [External], starting at rnalHD/Users/dossy/Work/Stuff_For_Your_Dog
The correct path is /Volumes/Alt-ExternalHD/Users/dossy/Work/Stuff_For_Your_Dog, so the initial 4 characters Exte are being trimmed off the start of the path.
Interestingly enough, the GUI does appear to be rendering the contents of the scan, but the paths are all malformed in this way.
I picked a small subfolder in that tree and did a -logAll YES scan, and interestingly enough, the files it enumerates do have the correct path in the output. I picked a single folder in the tree with no subfolders to minimize the amount of output:
$ /Applications/GrandPerspective.app/Contents/MacOS/GrandPerspective -logAlS YES
2025-05-02 14:32:08.889 GrandPerspective[76315:77737036] +[CATransaction synchronize] called within transaction
2025-05-02 14:32:16.390 GrandPerspective[76315:77737062] fastPackageCheckEnabled = 1
2025-05-02 14:32:16.392 GrandPerspective[76315:77737062] Volume format = APFS (Encrypted)
2025-05-02 14:32:16.392 GrandPerspective[76315:77737062] fstypename = apfs
2025-05-02 14:32:16.392 GrandPerspective[76315:77737062] ignoreHardLinksForDirectories = 1
2025-05-02 14:32:16.393 GrandPerspective[76315:77737062] Scanning volume /Volumes/External [External], starting at rnalHD/Users/dossy/Work/Stuff_For_Your_Dog/theme/config
2025-05-02 14:32:16.393 GrandPerspective[76315:77737062] Scanning /Volumes/Alt-ExternalHD/Users/dossy/Work/Stuff_For_Your_Dog/theme/config
2025-05-02 14:32:16.394 GrandPerspective[76315:77737062] Done scanning: 1 folders scanned (0 skipped) in 0.00s.
This issue only appears to be affecting scans of my external HD. Scanning a folder on my internal HD works correctly as expected:
2025-05-02 14:35:23.148 GrandPerspective[76924:77742411] +[CATransaction synchronize] called within transaction
2025-05-02 14:35:26.156 GrandPerspective[76924:77742456] fastPackageCheckEnabled = 1
2025-05-02 14:35:26.156 GrandPerspective[76924:77742456] Volume format = APFS
2025-05-02 14:35:26.156 GrandPerspective[76924:77742456] fstypename = apfs
2025-05-02 14:35:26.156 GrandPerspective[76924:77742456] ignoreHardLinksForDirectories = 1
2025-05-02 14:35:26.156 GrandPerspective[76924:77742456] Scanning volume / [Macintosh HD], starting at Users/dossy/Downloads
2025-05-02 14:35:26.157 GrandPerspective[76924:77742456] Scanning /Users/dossy/Downloads
2025-05-02 14:35:26.157 GrandPerspective[76924:77742456] Done scanning: 1 folders scanned (0 skipped) in 0.00s.
I have a feeling the issue is in the way macOS is mounting my external volumes and/or how I'm accessing them, and the fact that the drive is mounted as two volumes with different names:
$ ls -la /Volumes/
total 0
drwxr-xr-x 7 root wheel 224 May 2 10:42 .
drwxr-xr-x 20 root wheel 640 Jul 30 2024 ..
drwxr-xr-x 3 root wheel 96 Apr 30 09:24 .timemachine
drwxr-xr-x 23 root admin 736 Dec 9 2021 Alt-ExternalHD
drwxr-xr-x@ 29 root wheel 928 Feb 7 09:43 External
lrwxr-xr-x 1 root wheel 1 Apr 4 16:17 Macintosh HD -> /
drwxr-xr-x 3 root wheel 96 Aug 29 2024 Recovery
It's one external drive, with the APFS System Volume disk3s5 mounted on /Volumes/Alt-ExternalHD and the APFS Data Volume disk3s1 mounted on /Volumes/External, and GrandPerspective says it's scanning volume /Volumes/External but the actual paths are /Volumes/Alt-ExternalHD which it correctly shows in the "Scanning ..." lines.
I'm not sure why macOS behaves this way, but:
$ realpath /Volumes/External/Users/dossy
/Volumes/External/Users/dossy
$ pwd
/Volumes/External/Users/dossy
$ realpath .
/Volumes/Alt-ExternalHD/Users/dossy
Interestingly enough, when I try to scan /Volumes/External, the file file browser UI (Finder?) doesn't even show me the "External" volume as a choice (see attached screenshot).
I hope this is enough information for you to both reproduce the issue and implement a fix. If you need any more information, please let me know.
Discussion
Anonymous
Slight correction:
It's more than 4 characters that's being trimmed.
What's being copied is:
/Volumes/External/rnalHD/Users/dossy/[...]while the correct path is:
/Volumes/Alt-ExternalHD/Users/dossy/[...]If you overwrite the correct path with the prefix
/Volumes/Externalyou end up with:/Volumes/ExternalrnalHD/Users/dossy/[...]Then, insert the
/after/Volumes/Externaland it becomes:/Volumes/External/rnalHD/Users/dossy/[...]Hope this helps point in the correct direction of where this bug lives.
Thanks for the detailed report. Very helpful!
Unfortunately, I did not manage to reproduce the issue with my external drive. There it works as intended. So it seems somewhat specific to your particular set-up.
I suspect that the root-cause is in a macOS library function that is used to determine the volume root from a directory to scan (
NSURL getResourceValue:forKey:error:with keyNSURLVolumeURLKey). To confirm, I added some extra logging. Can you run the application in the zip (Bug-117.zip (sourceforge.net)) and share the logs?I expect that the volumeRoot that is reported for the URL is incorrect. In that case, I also expect that the Volume size and Initial free space reported in the Info panel to be incorrect. Can you confirm that as well?
Here's the output from this build:
I meanwhile created another build, which includes some fallback logic when the main method of determining the volume root failed. Can you try running that to see if that fixes the issue? If not, please share the logs.
The build with fallback logic: Bug-117-build-2
This second build works as expected:
Thanks!
Closing this issue. The fix will be included in the upcoming v3.5.3 release.
Thanks for the quick fix! Greatly appreciated.