|
|
6b.png (173,021 bytes) 6a.png (147,302 bytes) 5.png (232,905 bytes) 3.png (106,277 bytes) 1.png (117,171 bytes) |
|
|
Any update on this? (I do see it moved to Confirmed status.) Thanks |
|
|
I figured out by doing some research why this bug occurs. The following article at eclecticlight.co explains how folder icons work https://eclecticlight.co/2023/07/25/why-dont-custom-icons-work-properly-in-icloud-drive Ignore the part about icloud drive, and read the first paragraph under the header "How custom icons work". At the end of that paragraph it states that "there’s also a flag that is set in another xattr, this time of type com.apple.FinderInfo; for folder icons, that’s attached to the folder itself" When I performed the steps to reproduce the problem that I originally reported, Visual Differ needed to both create the colder containing the icon and copy the file containing the icon image that was within. When Visual Differ created the folder on the right hand side, it did not copy the com.apple.FinderInfo extended attribute from the original corresponding folder on the left side. This extended attribute contained data as follows xattr -p -x com.apple.FinderInfo "~/Desktop/Copy Test/test/FolderWithHDImage" 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 That "4" in the data is the bit flag to the Finder that a custom icon should be displayed. So that brings me to several questions: 1a) Am I correct that when Visual Differ copies a file that it copies ALL of its extended attributes with the file? 1b) Is the answer to question 1a affected by whether I check the option "Check Resource Forks" for the comparison phase? 2) Am I correct that when Visual Differ copies a folder that it copies NONE of the extended attributes of any kind that may be on the folder itself? (I know it does not copy com.apple.FinderInfo as proven by my test.) 3) Can you please fix this bug by ensuring that when Visual Differ has to create a folder during copying of files that the folder has identical extended attributes to the original folder? Thanks |
|
|
This article give more information about the com.apple.FinderInfo extended attribute https://eclecticlight.co/2017/12/19/xattr-com-apple-finderinfo-information-for-the-finder/ A reader comment points out that the Finder Information is documented in the FileInfo and ExtendedFileInfo structures in the CoreServices Framework (CarbonCore>Finder.h>). I also see that there are FolderInfo and ExtendedFolderInfo structs next to FileInfo and ExtendedFileInfo. |
|
|
Maybe I have fixed this bug, this night I implemented the fix and seems to work but it's necessary to do intensive testing. May you help me? May I send to you a copy of VD with this fix, obviously you are free to say no and I will continue to test myself ;) If you agree I will send to you the details at the email address used here at bugs.visualdiffer.com |
|
|
Yes, I would like to test your change. You may send it to me at the email address I registered for this Bug Reporter. Are there other changes being tested in this build, or is the build you are offering to send me have only the one change since the last release build? Thank you for continuing to work on Visual Differ! Can you please answer my questions I asked above, restated here... 1a) Am I correct that when Visual Differ copies a file that the current release build copies ALL of its extended attributes with the file? 1b) Is the answer to question 1a affected by whether I check the option "Check Resource Forks" for the comparison phase? 2) Am I correct that when Visual Differ copies a folder that the current release build copies NONE of the extended attributes of any kind that may be on the folder itself? (I know it does not copy com.apple.FinderInfo as proven by my test.) 3) (Revised) Does the bug fix you are working on copy all extended attributes that might be on folders, or just com.apple.FinderInfo? |
|
|
> Yes, I would like to test your change. You may send it to me at the email address I registered for this Bug Reporter. Thanks for your help > Are there other changes being > tested in this build, or is the build you are offering to send me have only the one change since the last release build? The current version on MAS do not contains this fix > > Thank you for continuing to work on Visual Differ! I'm trying to continue the work but very slowly > > Can you please answer my questions I asked above, restated here... > > 1a) Am I correct that when Visual Differ copies a file that the current release build copies ALL of its extended attributes with the file? The current version on Mac App Store do not copy extended attributes The fix copy all COPYFILE_METADATA attributes using the function copyfile documented here https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/copyfile.3.html > 1b) Is the answer to question 1a affected by whether I check the option "Check Resource Forks" for the comparison phase? The fix does not depend on "Check Resource Forks" flag, the fix copy all attributes only **for directories** (not normal file but only directories) > 2) Am I correct that when Visual Differ copies a folder that the current release build copies NONE of the extended attributes of any kind that may be > on the folder itself? (I know it does not copy com.apple.FinderInfo as proven by my test.) Yes, I confirm the current version on Mac App Store do not copy any extended attributes, Apple API requires multiple separated calls to obtain this result > 3) (Revised) Does the bug fix you are working on copy all extended attributes that might be on folders, or just com.apple.FinderInfo? The copyfile function copies all attributes but only for directories, maybe I must do for files, too |
|
|
Thanks for fixing this. You may close it. |
|
|
thanks for your feedback and patience |
- Anonymous
