View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000122||VisualDiffer||Folders differ||public||2012-08-05 06:15||2013-04-13 07:49|
|Platform||Mac||OS||OS X||OS Version||10.8|
|Target Version||Fixed in Version||1.5.2|
|Summary||0000122: Folder (package) containing a particular aliases see size hugely inflated (recursive alias?)|
|Description||A particular folder 1,5Mb in actual size (copy attached) which happened to contain some aliases (Symlinks?) was reported by VisualDiffer to be 8.32 Gb. |
When copied over from "Right" to "Left" by VisualDiffer, 1.5Mb of actual data on the left got transformed into gigabytes of data in the right side (recursively nested folders were created). After the operation, in the Finder, the size was found to be 1.5 Mb on the "left side" and 5.99Gb on the "right side" (not the 8.32 Gb initially determined by VisualDiffer on the "left side").
When I do the SAME copy operation using the Finder, only 1.5Mb gets correctly copied over.
I am attaching to this report the culprit folder (zipped). I think you will readily reproduce the issue.
Note that I did not create this data set, it was found within the package of a well-known commercial application (not saying which as I think it is irrelevant).
My superficial analysis points a particular alias "DotMacKit.framework" found in the app package ".MacMessageManager.app" that links to a point higher up in the same folder hierarchy, thereby creating a recursive loop. Instead of just copying the alias, VisualDiffer follows it and keeps copying/nesting the same data over and over recursively. Actually, I am surprised that it stops at some point, I would assume the app would have filled up my entire disk if not stopped manually, but it did stop after a few minutes.
I imagine that, had the alias pointed to external data (I mean external to the folder structure being analyzed by VisualDiffer) that external data would also have been copied, so the issue is not solely linked to weird aliases that kind of point to themselves.
|Steps To Reproduce||Unzip the file I am attaching (Frameworks.zip).|
Within VisualDiffer, create a new comparison and select that folder on the Left side. Select an empty folder on the right side and start the diff.
Examine the size reported by VisualDiffer on the left side (gigabyte) and compare it to the Finder size (1.5Mb).
Copy Left to Right and see the results.
|Tags||No tags attached.|
Frameworks.zip (528,375 bytes)
The summary I wrote is mistyped and a bit confusing.
Assuming my analysis is right, a better summary would be:
VisualDiffer replaces aliases/symlinks by the actual data they point to.
||Replacing aliases with 'real' destination sounds a bit ugly and may confuse user, honestly I as user should be confused to find a folder name (the name could be different) not present in original folder.|
I don't understand your comment (0000153).
I am not ASKING to replace an alias (symlink) with its destination, I am reporting it as a defect that it does replace an alias with its destination.
In a copy operation, an alias should be copied as an alias. Right now it seems that VisualDiffer follows the alias and copies the linked data. sometimes recursively.
But isn't this issue related to issue 127 ? In which case, it may already be fixed.
Please apologize my misunderstood, forget comment 0000153
Following the alias and copy files seems the best choice, suppose you copy only the alias on a flash drive when you try to access to files on another computer you may not be able to see files.
It sounds like a very advanced feature to let user to choose if follow alias or create the same on destination
Two comments on 0000161:
1- Have you tested with the file I attached? You should easily reproduce what I saw..
I think there is an issue of "*infinite* recursive calls" (as you expressed it in comment in issue 127/ 0000154). Here's what I observed: I copied a 1.5 Mb folder to the other side and the resulting folder was 5.99Gb in size, 4000 times bigger. And the copy took a very long time of course.
Now, this was caused by following a link, but NOT a link to external data! Instead, the folder contains somewhere inside a tree section that loops on itself via an alias (or rather a symlink). Consequently, the copy generates a series of nested folders, traversing the loop over and over. It should be infinite, but somehow it stops after apparently 4000 times instead of crashing.
If the looped tree section had been bigger than 1.5Mb, I guess it might very well have crashed, or maybe stop after completely filling the destination.
So this is a real issue... And I am convinced this is the same issue as 0000127, only in the context of copying instead of merely comparing.
Note that the Finder doesn't do this when it copies the same folder.
2- See next post...
Comment 2: For an "ordinary" Mac user, the reference is the Finder: a copy is what the Finder does, it doesn't follow links. Copy shouldn't have this special and unusual behavior, it is really confusing.
Sometimes I may appreciate that special feature to follow links, but I would see it as a special kind of Copy, something really different. So for the sake of "normal" Mac users, which I think is the public you are offering your app to now, you should call it something different if links are followed, maybe "Copy Special", "SuperCopy", whatever....
I understand the example you gave for wanting to follow links, and if some people need this, why not implement both then? You could have in the same menu the normal "Copy" and the special "Copy following links" - or else give the choice via preferences while defaulting to a normal copy; personally I would prefer to see both commands at once to pick and choose.
I came to this app with a different perspective. I merely want to reconcile messy folders of personal data across many disks. I am happy when I manage to identify two folder structures that are identical, because then I can delete one while knowing I haven't lost anything, and I have simplified my data set one step, and then I carry on...
So I compare folders, and when I find differences in similar folder structures, I copy to the other side to make both sides strictly identical. Then I rerun the comparison to make sure they are the same, no mistake, and then I can safely delete one side. That's all. I would never want to follow links!
Consider all applications I know use copy by follow, for example
BTW Using a preference sounds reasonable
Just a suggestion: how about using the Option modifier key?
This is very mac-like: A regular user would see Copy, and the expert would know to Option-click and see "Copy/Follow Links".
BTW, I understand where you are coming from. But I feel that VisualDiffer is different from those technical apps, VisualDiffer seems well suited for all hands now, and frankly, this is an app that I have been looking for years. I love the way it allows working visually to spot differences (still very confused with the color coding though). And I have talked to other regular end-users, with same needs as me.
I find that this issue is NOT fixed in version 1.5.1 as claimed
I tested again with the folder I originally provided as an example (see attached files) and visual differ still follows links:
1- Diffing the folder that I provided is ENDLESS (even though it is only 1.5Mb). I had to abort the diff!
2- "Copy to Right" or "Copy to left" recursively copies the same files overs and over until eventually the destination gets full. I had to abort the copy!
So VisualDiffer still appears to follow links when diffing and copying, with catastrophic consequences when a link points to a parent folder (which is a possible and legitimate situation to have)
Please apologize me, bug has been fixed in v1.5.2 that I've submitted today to MAS, I've selected the wrong value from versions combo
In a couple of weeks (I hope less) the new version should be available.
Have you verified on version 1.5.2?
May I close this bug?
I can confirm fixed in 1.5.2
- Verified fixed when comparing
- Verified fixed also when copying Left to Right, or vice-versa
||I'm very happy to hear everything works fine, thanks for your feedback.|
|2012-08-05 06:15||evolution||New Issue|
|2012-08-05 06:15||evolution||Status||new => assigned|
|2012-08-05 06:15||evolution||Assigned To||=> admin|
|2012-08-05 06:15||evolution||File Added: Frameworks.zip|
|2012-08-05 07:23||evolution||Note Added: 0000139|
|2012-08-05 08:09||admin||Status||assigned => confirmed|
|2012-08-18 10:36||admin||Note Added: 0000153|
|2012-09-02 03:22||evolution||Note Added: 0000157|
|2012-09-02 09:44||admin||Note Added: 0000161|
|2012-09-02 09:44||admin||Note Edited: 0000161||View Revisions|
|2012-09-02 10:30||evolution||Note Added: 0000165|
|2012-09-02 11:27||evolution||Note Added: 0000166|
|2012-09-02 11:31||admin||Note Added: 0000167|
|2012-09-02 12:02||evolution||Note Added: 0000171|
|2013-03-01 10:43||admin||Status||confirmed => closed|
|2013-03-01 10:43||admin||Resolution||open => fixed|
|2013-03-01 10:43||admin||Fixed in Version||=> 1.5.1|
|2013-03-15 11:30||evolution||Note Added: 0000237|
|2013-03-15 11:30||evolution||Status||closed => feedback|
|2013-03-15 11:30||evolution||Resolution||fixed => reopened|
|2013-03-15 11:44||admin||Note Added: 0000238|
|2013-03-15 11:44||admin||Fixed in Version||1.5.1 => 1.5.2|
|2013-04-12 08:05||admin||Note Added: 0000265|
|2013-04-12 16:12||evolution||Note Added: 0000267|
|2013-04-12 16:12||evolution||Status||feedback => assigned|
|2013-04-12 17:02||admin||Note Added: 0000269|
|2013-04-13 07:49||admin||Status||assigned => closed|
|2013-04-13 07:49||admin||Resolution||reopened => fixed|