Re: diff mishandling symlinks



On Sun, 20 May 2007 22:43:38 -0000 Gordon Burditt <gordonb.nggh9@xxxxxxxxxxx> wrote:
|>|> The "diff" command, when used with the '-ur' option to create a difference
|>|> between two source file trees, does not appear to handle symlinks very well
|>|> at all. I have made a change in symlinks that "diff" fails to recognize.
|>|> It seems that "diff" wants to compare the contents of the files symlinks
|>|> point to, rather than the symlink vector itself. If the vector changes,
|>|> and the target files are still the same, "diff" won't see it as a change.
|>|> And if the files are different, all you get is the file contents change.
|>|> Something makes me think "patch" doesn't handle symlinks, either.
|>|
|>| I wouldn't consider this "mishandling". diff and patch deal with the
|>| *contents* of files and so ignore symlink issues.
|>
|>"Dealing with the contents" of files does not do a complete job of making
|>the kinds of diffs that can show changes in file trees that contain things
|>other than regular files.
|>
|>Maybe this erroneous approach is why virtually all version control systems
|>just can't handle all possible filesystem elements, such as symlinks.
|
| Many "version control systems" are also called "source code control
| systems", and as such, what matters is the contents of the file,
| not what maze of symlinks I go through to get to them. Also consider
| that absolute paths in symlinks cause problems for network-capable
| "source code control systems" since the paths may not exist on all
| systems. One thing common about these systems is the ability to
| check out your own working copy, or multiple sets of them, that
| don't interfere with each other or the stored version until you
| check changes back in.

There are some valid uses for symlinks. But maybe because they don't work
in certain version control systems, those who use those systems has avoided
using symlinks. But I guess in my case I'll avoid using those version
control systems, instead.


| A very complete "diff" would say every file is different from every
| other file because the inode numbers are different, unless the files
| in the two versions were the same file with multiple hard links.
| This I consider to be "noise" and even worse. The same applies to
| owner and group on files. If you propose changing the default
| behavior of diff, I consider this to be a seriously bad idea. If
| you want your behavior with an option, fine, as long as it's not a
| default.

An option is fine.


| I do wish diff would have better recognition of the distinction
| between a NONEXISTENT file and an EMPTY file. Usually it isn't
| a problem.

An option for that is fine, too. I wouldn't object as default, either.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-05-21-0725@xxxxxxxx |
|------------------------------------/-------------------------------------|
.



Relevant Pages

  • Re: diff mishandling symlinks
    ... I have made a change in symlinks that "diff" fails to recognize. ... Maybe this erroneous approach is why virtually all version control systems ... Many "version control systems" are also called "source code control ...
    (comp.unix.programmer)
  • Re: diff mishandling symlinks
    ... diff and patch deal with the ... |>just can't handle all possible filesystem elements, such as symlinks. ... | In this case, you should think about the fact that diff predates symlinks, ... | and that the early versions of diff didn't do recursion at all. ...
    (comp.unix.programmer)
  • Re: diff mishandling symlinks
    ... I have made a change in symlinks that "diff" fails to recognize. ... rather than the symlink vector itself. ... the kinds of diffs that can show changes in file trees that contain things ...
    (comp.unix.programmer)
  • diff mishandling symlinks
    ... between two source file trees, does not appear to handle symlinks very well ... I have made a change in symlinks that "diff" fails to recognize. ... rather than the symlink vector itself. ...
    (comp.unix.programmer)