View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000320 | VisualDiffer | Folders differ | public | 2019-01-22 01:23 | 2022-01-02 07:35 |
| Reporter | tkmantis | Assigned To | admin | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.6.6 | ||||
| Fixed in Version | 1.8.5 | ||||
| Summary | 0000320: Folder compare fails to detect a buried empty folder not on other side | ||||
| Description | If I have an empty folder buried in one side of the comparison several levels deep and the other side of the comparison is the same except that empty folder is missing, I cannot see that there is a difference. Sometimes I might have a note to myself as the name of an empty folder and I would like to be able to detect if such empty folder is missing on one side of a folder comparision. | ||||
| Steps To Reproduce | 1. Start with two empty disk partitions or two empty folders named "a" and "b". 2. These will become the left and right side of a folder compare. 3. Make a new empty folder in "a" and do not open it (do not create a .DS_Store inside of it) 4. Copy that empty new folder into "b" 5. Copy the new folder from "a" inside of the new folder you just copied to "b" so that "b" has a buried empty folder 6. Do a compare of "a" and "b" in visual differ 7. Observe that the two folders shown in Visual Differ appear gray, as in no difference. Realize that while one can expand the folders in Visual Differ to look, in a real compare, there will be thousands of files and folders and that an empty folder could be buried deep. I would like to be able to tell if there is a difference, even if the difference is only the presence or absence of an empty folder. | ||||
| Additional Information | Question: Are you still maintaining this app? There has been no update in almost a year. | ||||
| Tags | No tags attached. | ||||
|
|
I reported this nearly three years ago. Can you please enable the app to detect missing empty folders? |
|
|
This is a nasty bug, every time I try to fix it I break something else. I hope to find a valid solution, thanks for using VD for so long time |
|
|
Just to be clear, may you confirm you want the result shown in screenshot? The current (wrong) result https://visualdiffer.com/vdbugs-screenshots/bug320/bug320-wrongResult.png The expected result https://visualdiffer.com/vdbugs-screenshots/bug320/bug320-fixedResult.png |
|
|
It looks like you have it right now, so long as that blue color with go all the way up the chain if the differing empty folder is buried many levels deep. |
|
|
Yes the full subtree must be "blue", also the parent folders must show the correct color. I'm doing many tests especially when copy/delete/move files but this feature requires more careful users, are you available to test an alpha version? I can send to you a copy of the alpha version, you don't need to uninstall the official one, just copy the alpha where you prefer (also out of Applications directory) run and use it |
|
|
In regard of the risk of breaking something else, I am curious whether you were able to limit your code changes for this fix to impact only the code that decides the colors to show in the result? I am assuming that I will still need to click the "empty" button for empty folders to be able to show. You can send me an alpha version, but I will not have a lot of time to test it extensively, and would wonder what you see as the areas of risk to existing code for your new programming change to better decide what test cases would be needed. Thanks for working on this! |
|
|
> In regard of the risk of breaking something else, I am curious whether you were able to limit your code changes for this fix to impact only the code that decides the colors to show in the result? The first fix implementation introduced a regression picking the wrong color combination, consider folders can have two (or three) colors > I am assuming that I will still need to click the "empty" button for empty folders to be able to show Yes, this is by design, user must choose to see empty folders > You can send me an alpha version, but I will not have a lot of time to test it extensively, Don't worry I don't want to bother you, I will send the alpha only if necessary > and would wonder what you see as the areas of risk to existing code for your new programming change to better decide what test cases would be needed. The test cases must check the colors after copy/delete/move files (containing empty folders), I'm writing the Unit tests to reproduce this actions but no test suite is perfect > Thanks for working on this! Thanks for your patience |
|
|
Bug fixed, I hope to publish on MAS in a couple of days |
|
|
I have updated Visual Differ and have a question about this feature/fix. Suppose I have a shallowly buried empty folder "106APPLE" as shown in picture 1, righthand side. (This folder contains only a .DS_Store file). In picture 1, I have "Empty" turned on and the result looks as I would expect. However in Picture 2, I turned off "Empty" and I still see the parent folder "8jr" colored blue, while the 106APPLE no longer appears. It seems that when "Empty" is turned off, then the folder "8jr", also should not be colored, since it only contains differences pertaining to empty folders. Am I correct? (BTW, I have "NAME IS .DS_Store" in my File Filters.) |
|
|
Here are the pictures for my latest comment... |
|
|
> However in Picture 2, I turned off "Empty" and I still see the parent folder "8jr" colored blue, while the 106APPLE no longer appears. It seems that when "Empty" is turned off, then the folder "8jr", also should not be colored, since it only contains differences pertaining to empty folders. Am I correct? You are correct, this is a bug (or better a regression), the correct visualization is shown in the picture at https://visualdiffer.com/vdbugs-screenshots/bug320/bug320-regression.png I've already fixed the bug and everything seems correct now, I'm not asking if you want to try an alpha version because I know you don't want to... |
|
|
I noticed that if I turn on both "Only Mismatches" and "Empty" that all the folders appear in gray on both sides when there are no differences and no orphan buried empty folders within the folders. It seems with these two options combined, that folders should appear only if there are differences in files or orphan buried folders within. |
|
|
Probably I'm wrong but behaviour seems correct to me |
|
|
I do think you are wrong. The whole point of "Only Mismatches" is to show only the mismatches. So when we have folders at the top level of the compare, the folders should show only if there are mismatches within the folders, such as differences in files, or, in cases when "Empty" is turned on, also if there are buried orphan empty folders. Thanks |
|
|
Probably my bad english, probably my burned brain but I don't understand. For me the result shown in the screenshoot below is correct. May you show a scenario (with screenshot) with the error? https://visualdiffer.com/vdbugs-screenshots/bug320/bug320_note_0000686.png |
|
|
In your last picture, .MISC, 101APPLE, and 103APPLE should not appear at all because you have "Only Mismatches" turned on. I attach another picture for "Only Mismatches" and "Empty" used together. 1) The folders _Band71dupeaway and Bravado Coffee Table have no differences and should not appear at all with "Only Mismatches" turned on. (One of these two folders is top level and the other is nested.) 2) The folder named "empty" actually is empty and correctly triggers 101APPLE_ to turn blue. 3) IMG_2048 copy.JPG is extra on the right and correctly triggers 102APPLE_ to turn blue. 4) _new Band71 is correctly blue, because of items 2) and 3). |
|
|
Ok, I see the problem... |
|
|
Some progress on the fix, based on your last picture directories structure https://visualdiffer.com/vdbugs-screenshots/bug320/bug320_note_0000690.png |
|
|
Yes, that looks like you have it right. "_Band71dupeaway" and "Bravado Coffee Table" are now properly removed for "Only Mismatches" and "empty folder" correctly shows up due to "Empty" also being selected. |
|
|
Regression fixed and patched version available on MAS |
|
|
Looks like this is fixed now. Thanks! Hoping you can move on to the other folder issue 0000342. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-01-22 01:23 | tkmantis | New Issue | |
| 2019-01-22 01:23 | tkmantis | Status | new => assigned |
| 2019-01-22 01:23 | tkmantis | Assigned To | => admin |
| 2021-01-03 09:59 | admin | Status | assigned => confirmed |
| 2021-10-29 20:08 | tkmantis | Note Added: 0000664 | |
| 2021-10-31 07:57 | admin | Note Added: 0000666 | |
| 2021-10-31 14:05 | admin | Note Added: 0000667 | |
| 2021-11-01 01:57 | tkmantis | Note Added: 0000668 | |
| 2021-11-01 14:29 | admin | Note Added: 0000670 | |
| 2021-11-01 14:30 | admin | Note Edited: 0000670 | |
| 2021-11-01 16:14 | tkmantis | Note Added: 0000671 | |
| 2021-11-02 09:16 | admin | Note Added: 0000672 | |
| 2021-11-06 09:44 | admin | Status | confirmed => resolved |
| 2021-11-06 09:44 | admin | Resolution | open => fixed |
| 2021-11-06 09:44 | admin | Note Added: 0000673 | |
| 2021-11-06 09:46 | admin | Fixed in Version | => 1.8.3 |
| 2021-11-07 09:21 | admin | Status | resolved => closed |
| 2021-11-13 06:50 | tkmantis | Status | closed => feedback |
| 2021-11-13 06:50 | tkmantis | Resolution | fixed => reopened |
| 2021-11-13 06:50 | tkmantis | Note Added: 0000679 | |
| 2021-11-13 06:51 | tkmantis | File Added: Picture 1.png | |
| 2021-11-13 06:51 | tkmantis | File Added: Picture 2.png | |
| 2021-11-13 06:51 | tkmantis | Note Added: 0000680 | |
| 2021-11-13 06:51 | tkmantis | Status | feedback => assigned |
| 2021-11-13 15:28 | admin | Note Added: 0000681 | |
| 2021-11-13 15:28 | admin | Status | assigned => confirmed |
| 2021-11-14 18:05 | tkmantis | Note Added: 0000682 | |
| 2021-11-15 06:26 | admin | Note Added: 0000684 | |
| 2021-11-15 16:18 | tkmantis | Note Added: 0000686 | |
| 2021-11-16 10:42 | admin | Note Added: 0000688 | |
| 2021-11-16 16:31 | tkmantis | File Added: Picture 3.png | |
| 2021-11-16 16:31 | tkmantis | Note Added: 0000690 | |
| 2021-11-17 10:52 | admin | Note Added: 0000693 | |
| 2021-11-20 12:15 | admin | Note Added: 0000697 | |
| 2021-11-22 08:17 | tkmantis | Note Added: 0000698 | |
| 2021-11-28 07:49 | admin | Note Added: 0000700 | |
| 2021-12-02 06:41 | tkmantis | Note Added: 0000701 | |
| 2022-01-02 07:35 | admin | Status | confirmed => closed |
| 2022-01-02 07:35 | admin | Resolution | reopened => fixed |
| 2022-01-02 07:35 | admin | Fixed in Version | 1.8.3 => 1.8.5 |
