bug#28245: 26.0.50; symbolic links not well handled by vc-dir

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Vincent Belaïche]

Hello, I have a project under SVN version control. Under the directory
under change control I have a test directory, call it `trunk/test', in
which a symbolic link is created to another file, call it
`trunk/scr/foo', for the purpose of test. So the symbolic link is
`trunk/foo' pointing at `trunk/src/foo'. `trunk/foo' is not under change
control, it is created by the test makefile, while `trunk/src/foo' is
under change control.

Please note that I am under MSW, I have created the symbolic links as
native NTFS symbolic links thanks to MSYS2 ln command --- by default
this command makes a copy, but it is possible to configure MSYS2 to have
native symlinks.

OK, `trunk/src/foo' is edited, and when I do `M-x vc-dir', I see in the
list of edited files `trunk/src/foo' twice. That is, IMHO, a bug.

BR,
	Vincent.




In GNU Emacs 26.0.50 (build 1, i686-pc-mingw32)
 of 2017-07-02 built on AIGLEROYAL
Repository revision: 3bab927884c4b795f8545b632328b5d3b632eed3
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Recent messages:
Parsing c:/Users/Vincent/AppData/Roaming/.mailrc... done
Mark set
Auto-saving...done
Making completion list...
Mark set
Making completion list...
You can run the command ‘vc-dir’ with C-x v d
Mark set
funcall-interactively: Buffer is read-only: #<buffer *vc-dir*<dssmith>>
Making completion list...

Configured using:
 'configure --prefix=c:/Nos_Programmes/GNU/Emacs --without-jpeg
 --without-tiff --without-gif --without-png 'CFLAGS= -Og -g3 -L
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src' 'CPPFLAGS=
 -DFOR_MSW=1 -I
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/include -I
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src -L
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src'
 PKG_CONFIG=/mingw/bin/pkg-config.exe PKG_CONFIG_PATH=/mingw/bin'

Configured features:
XPM SOUND NOTIFY ACL GNUTLS TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: FRA
  locale-coding-system: cp1252

Major mode: VC dir

Minor modes in effect:
  TeX-PDF-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs hides c:/Nos_Programmes/GNU/Emacs/share/emacs/26.0.50/lisp/loaddefs
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs hides c:/Programmes/installation/cedet-install/cedet-git/lisp/cedet/loaddefs

Features:
(shadow emacsbug bug-reference cal-china lunar solar cal-dst cal-bahai
cal-islam cal-hebrew cal-julian holidays hol-loaddefs diary-lib
diary-loaddefs warnings vc-annotate vc-filewise calc-lang calc-stuff
ps-mode calc-embed calc-store calc-undo calc-incom rng-xsd xsd-regexp
rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse nxml-parse
rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode nxml-outln
nxml-rap sgml-mode dom nxml-util nxml-enc xmltok ltx-help m4-mode
cal-iso cal-move whitespace calc-units calc-aent log-edit pcvs-util
vc-rcs vc-dir ewoc tabify org-table url-util browse-url conf-mode
visual-basic-mode cc-dxl cc-mode cc-guess cc-menus cc-cmds cc-styles
cc-align cc-langs cc-fonts cc-engine cc-vars cc-defs cc-bytecomp vc-cvs
balance eieio-compat calc-yank calc-mode lpr org-element org-rmail
org-mhe org-irc org-info org-gnus org-docview doc-view jka-compr
image-mode org-bibtex bibtex org-bbdb org-w3m org org-macro org-footnote
org-pcomplete org-list org-faces org-entities org-version ob-emacs-lisp
ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint
ob-core ob-eval org-compat org-macs org-loaddefs cal-tex cal-menu
calendar cal-loaddefs iso-transl quail sh-script smie executable
calc-map calc-vec calc-stat calccomp hl-line ses unsafep ispell loadhist
ibuf-ext ibuffer ibuffer-loaddefs debug cus-edit cus-start cus-load
bbdb-tex flow-fill map vc-svn tex-info texinfo add-log autoconf
autoconf-mode calc-math calc-alg calc-forms calc-menu info vc
vc-dispatcher ediff-vers ediff-merg ediff-wind ediff-diff ediff-mult
ediff-help ediff-init ediff-util ediff bat-mode pcmpl-unix reftex-auc
texmathp latexenc reftex-parse rect pp cl-print preview prv-emacs
reftex-dcr reftex reftex-loaddefs reftex-vars noutline outline mailalias
smtpmail canlock make-mode tex-bar latex tex-style toolbar-x font-latex
plain-tex tex-buf tex advice tex-mode shell pcomplete vc-git diff-mode
easy-mmode bbdb-message sendmail find-dired semantic/fw mode-local xref
project grep compile comint ring thingatpt eieio-opt speedbar sb-image
ezimage dframe find-func help-fns radix-tree nnir sort ansi-color
gnus-cite mm-archive mail-extr gnus-bcklg gnus-async qp gnus-ml
cursor-sensor nndraft nnmh nnfolder cl-extra help-mode bbdb-gnus
bbdb-mua bbdb-com crm misearch multi-isearch dired-aux network-stream
nsm starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp
gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap
nnmail mail-source tls gnutls utf7 netrc nnoo parse-time gnus-spec
gnus-int gnus-range message subr-x puny dired-x dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus-win
gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
mail-utils mm-util mail-prsvr edmacro kmacro skeleton calc-misc
calc-arith calc-ext calc calc-loaddefs calc-macs tex-mik preview-latex
tex-site auto-loads bbdb bbdb-site timezone bbdb-loaddefs template
w32utils cl recentf tree-widget wid-edit load-path-to-cedet-svn
finder-inf package easymenu epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 8 1400083 260824)
 (symbols 32 62370 1)
 (miscs 32 3383 5686)
 (strings 16 212563 28349)
 (string-bytes 1 6997868)
 (vectors 8 77650)
 (vector-slots 4 2079364 66492)
 (floats 8 976 1177)
 (intervals 28 113737 2616)
 (buffers 516 244))

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Eli Zaretskii]

> From: vincent.belaiche@gmail.com (Vincent Belaïche)
> Date: Sat, 26 Aug 2017 23:02:55 +0200
> Cc: Vincent Belaïche <vincent.belaiche@gmail.com>
> 
> Hello, I have a project under SVN version control. Under the directory
> under change control I have a test directory, call it `trunk/test', in
> which a symbolic link is created to another file, call it
> `trunk/scr/foo', for the purpose of test. So the symbolic link is
> `trunk/foo' pointing at `trunk/src/foo'. `trunk/foo' is not under change
> control, it is created by the test makefile, while `trunk/src/foo' is
> under change control.
> 
> Please note that I am under MSW, I have created the symbolic links as
> native NTFS symbolic links thanks to MSYS2 ln command --- by default
> this command makes a copy, but it is possible to configure MSYS2 to have
> native symlinks.
> 
> OK, `trunk/src/foo' is edited, and when I do `M-x vc-dir', I see in the
> list of edited files `trunk/src/foo' twice. That is, IMHO, a bug.

vc-dir calls the SVN backend to collect its information, and according
to my references, SVN doesn't support symlinks on MS-Windows.  Does
your port of SVN support symlinks?  What does "svn status -v" show in
that repository?

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Vincent Belaïche]

My answers bellow...

Le 27/08/2017 à 16:21, Eli Zaretskii a écrit :
>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>> Date: Sat, 26 Aug 2017 23:02:55 +0200
>> Cc: Vincent Belaïche <vincent.belaiche@gmail.com>
>>
>> Hello, I have a project under SVN version control. Under the directory
>> under change control I have a test directory, call it `trunk/test', in
>> which a symbolic link is created to another file, call it
>> `trunk/scr/foo', for the purpose of test. So the symbolic link is
>> `trunk/foo' pointing at `trunk/src/foo'. `trunk/foo' is not under change
>> control, it is created by the test makefile, while `trunk/src/foo' is
>> under change control.
>>
>> Please note that I am under MSW, I have created the symbolic links as
>> native NTFS symbolic links thanks to MSYS2 ln command --- by default
>> this command makes a copy, but it is possible to configure MSYS2 to have
>> native symlinks.
>>
>> OK, `trunk/src/foo' is edited, and when I do `M-x vc-dir', I see in the
>> list of edited files `trunk/src/foo' twice. That is, IMHO, a bug.
>
> vc-dir calls the SVN backend to collect its information, and according
> to my references, SVN doesn't support symlinks on MS-Windows.

You are correct, SVN doesn't support symlinks on MS-Windows. So, it
might well be that nothing is to be done on the Emacs side. But please
read the following...

> Does your port of SVN support symlinks?

FYI, my port is the collabnet one.

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
$ svn --version
svn, version 1.8.13 (r1667537)
   compiled Mar 23 2015, 03:35:53 on x86_64/x86-microsoft-windows5.1.2600

Copyright (C) 2014 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - using serf 1.3.8
  - handles 'http' scheme
  - handles 'https' scheme
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

It does not support symlinks to the extent that if there is a symlink in
the repo, then the symlink is not created by a chekcout in the work
area. Instead a plain file containing the link information is
created. However, if I create manually the symlink in place of this
file, then subsequent svn update won't overwrite it.

Now, here, we are not talking about a symlink in the repo, this is a
symlink created locally and which is not under version control.

> What does "svn status -v" show in that repository?

When I do that, I see the original file `foo' only once. Please note
that my bug report is erroneous. Actually, the symlink is
trunk/test/foo, pointing as trunk/src/foo. trunk/src/foo is under change
control, but the directory trunk/test and all its content is not under
change control --- I have not yet imported it. So `svn status -v' done
under trunk shows only, as far as trunk/test and its content are
concerned, this:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
?                                        test
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

My intention was to import trunk/test to the repo with only the files
under trunk/test that aren't created by the test, so the symlinks would
in the end not be under change control, which anyway is impossible
because my SVN client does not support symlinks.

  Vincent.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Emacs developers will work on fixing this specific problem,
but the larger underlying problem is one that only you can fix:

  > Please note that I am under MSW,

Windows does you constant injustice because it is nonfree software.
See https://gnu.org/philosophy/free-software-even-more-important.html.

It is also malware: see https://gnu.org/malware/malware-microsoft.html.

Please do not interpret our support for running GNU Emacs on Windows
as granting Windows legitimacy.  For your freedom's sake, you need to
get out from under it!

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Eli Zaretskii]

> From: vincent.belaiche@gmail.com (Vincent Belaïche)
> Cc: Vincent Belaïche <vincent.belaiche@gmail.com> 
> Date: Sun, 27 Aug 2017 22:52:53 +0200
> 
> > What does "svn status -v" show in that repository?
> 
> When I do that, I see the original file `foo' only once. Please note
> that my bug report is erroneous. Actually, the symlink is
> trunk/test/foo, pointing as trunk/src/foo. trunk/src/foo is under change
> control, but the directory trunk/test and all its content is not under
> change control --- I have not yet imported it. So `svn status -v' done
> under trunk shows only, as far as trunk/test and its content are
> concerned, this:
> 
> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
> ?                                        test
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

Then maybe "svn status -v" is not the right (or not the only) command
you should try.  My point is that you should find out which SVN
commands are invoked by vc-dir in this use case, and then see what did
SVN produce for these commands outside of Emacs.

It also could be that this is not a Windows-specific issue.

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Glenn Morris]

Eli Zaretskii wrote:

> It also could be that this is not a Windows-specific issue.

I find the report unclear, but on GNU/Linux:

cd /tmp
mkdir svn
cd svn
svnadmin create repo
mkdir -p trunk/src
touch trunk/src/foo
svn import trunk file://$PWD/repo/trunk -m "Import"
rm -rf trunk
svn checkout file://$PWD/repo/trunk
echo blah >> trunk/src/foo
mkdir trunk/test
cd trunk/test
ln -s ../src/foo
cd ../
emacs -Q -f vc-dir RET

and everything looks correct to me.

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: vincent.belaiche@gmail.com (Vincent Belaïche),
>   28245@debbugs.gnu.org
> Date: Mon, 28 Aug 2017 14:13:35 -0400
> 
> emacs -Q -f vc-dir RET
> 
> and everything looks correct to me.

One problem with this bug report, at least from my POV, is that
neither Vincent nor you actually _show_ what you see in vc-dir.  So
it's hard for me to even reason what is and isn't "correct".

(And I think your directory structure is not what Vincent described,
although I can understand how you could be confused, since he made a
couple of mistakes describing it.)

Thanks.

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Glenn Morris]

Eli Zaretskii wrote:

> One problem with this bug report, at least from my POV, is that
> neither Vincent nor you actually _show_ what you see in vc-dir.  So
> it's hard for me to even reason what is and isn't "correct".

I gave a recipe you could follow on eg fencepost, and see for yourself.
Here it looks like:

VC backend : SVN
Working dir: /tmp/svn/trunk/
Repository : file:///tmp/svn/repo

                         ./
    unregistered         test
                         src/
    edited               src/foo


IMO it will be unproductive to debug this further without a similar
recipe from Vincent.

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: vincent.belaiche@gmail.com,  28245@debbugs.gnu.org
> Date: Mon, 28 Aug 2017 14:33:50 -0400
> 
> VC backend : SVN
> Working dir: /tmp/svn/trunk/
> Repository : file:///tmp/svn/repo
> 
>                          ./
>     unregistered         test
>                          src/
>     edited               src/foo

Thanks.

> IMO it will be unproductive to debug this further without a similar
> recipe from Vincent.

Indeed.

bug#28245: 26.0.50; symbolic links not well handled by vc-dir

[Vincent Belaïche]

Le 28/08/2017 à 20:38, Eli Zaretskii a écrit :
>> From: Glenn Morris <rgm@gnu.org>
>> Cc: vincent.belaiche@gmail.com,  28245@debbugs.gnu.org
>> Date: Mon, 28 Aug 2017 14:33:50 -0400
>>
>> VC backend : SVN
>> Working dir: /tmp/svn/trunk/
>> Repository : file:///tmp/svn/repo
>>
>>                           ./
>>      unregistered         test
>>                           src/
>>      edited               src/foo
> Thanks.
>
>> IMO it will be unproductive to debug this further without a similar
>> recipe from Vincent.
> Indeed.
I need to prepare a minimal example to reproduce the problem which I saw.
That might be not so easy, as I cannot reproduce it any longer on the 
work area in which I observed it.
So, please be patients gentlemen.

   Vincent.

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus