file-attributes inconsistent w. stat when .. or . symlinked

file-attributes inconsistent w. stat when .. or . symlinked

[Vivek Dasmohapatra]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2003-06-06 on arachne, modified by Debian
configured using `configure  i386-linux --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: ja_JP
  value of $LC_CTYPE: ja_JP
  value of $LC_MESSAGES: en_GB
  value of $LC_MONETARY: en_GB
  value of $LC_NUMERIC: en_GB
  value of $LC_TIME: en_GB
  value of $LANG: ja_JP
  locale-coding-system: japanese-iso-8bit
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

If (for example) "/usr/src/linux" is a symlink, then stat 
and file-attributes differ in their treatment of "." in 
/usr/src/linux:

Using the stat command:
vivek@arachne:/usr/src/linux$ stat /usr/src/linux/.
  File: "/usr/src/linux/."
  Size: 4096            Blocks: 8          IO Block: 4096   Directory
Device: 303h/771d       Inode: 49090       Links: 14   
Access: (0755/drwxr-xr-x)  Uid: ( 1046/x-royston)   Gid: (  101/ telnetd)
Access: Tue Sep  2 15:34:49 2003
Modify: Mon Aug  4 17:28:57 2003
Change: Mon Aug  4 17:28:57 2003

vivek@arachne:/usr/src/linux$ stat /usr/src/linux  
  File: "/usr/src/linux" -> "kernel-source-2.4.7"
  Size: 19              Blocks: 0          IO Block: 4096   Symbolic Link
Device: 303h/771d       Inode: 35387       Links: 1    
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (   40/     src)
Access: Tue Sep  2 15:39:03 2003
Modify: Mon Aug  4 17:26:20 2003
Change: Mon Aug  4 17:26:20 2003

However, using file-attributes:

This one is Ok, as expected:

M-: (insert (pp (file-attributes "/usr/src/linux")))
("kernel-source-2.4.7" 1 0 40
 (16212 43914)
 (16174 35116)
 (16174 35116)
 19 "lrwxrwxrwx" t 35387 771)

This is not so good:

M-: (insert (pp (file-attributes "/usr/src/linux/.")))
("kernel-source-2.4.7" 1 0 40
 (16212 43991)
 (16174 35116)
 (16174 35116)
 19 "lrwxrwxrwx" t 35387 771)

And neither is this:

M-: (progn (cd "/usr/src/linux") (insert (pp (file-attributes "."))))
("kernel-source-2.4.7" 1 0 40
 (16212 44166)
 (16174 35116)
 (16174 35116)
 19 "lrwxrwxrwx" t 35387 771)

Which has the nasty effect of returning duff symlink data, especially 
when considering ls-lisp output:

  /usr/src/linux:
  total 2660  free 418244
  drwxrwsr-x   3 0        40           4096 Aug  4 17:26 ..
  drwxr-xr-x  27 1046     telnetd      4096 Jul 20  2001 Documentation
  .
  .
  .
  lrwxrwxrwx   1 0        40             19 Aug  4 17:26 . -> kernel-source-2.4.7

This is also a problem one level down:

  /usr/src/linux/fs:
  total 1232  free 418244
  drwxr-xr-x  40 1046     telnetd      4096 Aug  2  2001 .
  drwxr-xr-x   2 1046     telnetd      4096 Jul 30  2001 adfs
  .
  .
  .
  lrwxrwxrwx   1 0        40             19 Aug  4 17:26 .. -> kernel-source-2.4.7

Again, stat does not consider ".." to be a symlink, but file-attributes
and similar in emacs do.

I submitted a patch to ls-lisp earlier, based on my assumption that 
it was ls-lisp that was at fault: However, it does look like 
file-attributes and directory-files-and-attributes is feeding it
bad values when the "." or ".." by which we arrived in a directory 
(from the current path's perspective) was a symlink.

Actually, thinking about it, that patch [see below] stands, imo, 
it just doesn't cover the `.. in our path was a symlink' case.

If file-attributes isn't likely to change, "." and ".." can be 
special cased in the chunk of code below as well, which fixes 
ls-lisp in any case.

--- dist/ls-lisp.el	Wed Dec  4 12:38:27 2002
+++ patched/ls-lisp.el	Mon Jul 14 15:46:44 2003
@@ -384,9 +384,13 @@
   ;; ordering, and reverse whole list.  cadr of each element of
   ;; `file-alist' is t for directory, string (name linked to) for
   ;; symbolic link, or nil.
-      (let (el dirs files)
+      (let (el dirs files dir-or-link)
 	(while file-alist
-	  (if (eq (cadr (setq el (car file-alist))) t) ; directory
+          (setq el          (car  file-alist)
+                dir-or-link (cadr el        ))
+	  (if (and dir-or-link
+                   (or (eq dir-or-link   t)             ; directory
+                       (file-directory-p dir-or-link))) ; symlink to dir
 	      (setq dirs (cons el dirs))
 	    (setq files (cons el files)))
 	  (setq file-alist (cdr file-alist)))

Re: file-attributes inconsistent w. stat when .. or . symlinked

[Richard Stallman]

I am not sure whether file-attributes should be changed,
so for the nonce we should fix this in ls-lisp.el.

Thanks.

Re: file-attributes inconsistent w. stat when .. or . symlinked

[Vivek]

On Sun, 7 Sep 2003, Richard Stallman wrote:

> I am not sure whether file-attributes should be changed,
> so for the nonce we should fix this in ls-lisp.el.
>
> Thanks.

No problem - the docs do say that the car of the list returned is the
name linked to, and for "." and ".." this is inconsistent with other
symlinks: For every other possible symlinked filename you can then call
`file-attributes' or `file-symlink-p' on the car of the returned value
and get a sensible answer, whereas for these two filenames ( or
presumably their equivalents on other platforms ) the caller has to
treat the values as special cases, so I would at least lean towards
changing the reported target filename to be relative to the directory
you're currently in for those two cases, rather than the directory above,
as it is now.

Re: file-attributes inconsistent w. stat when .. or . symlinked

[Richard Stallman]

What's happening is that Emacs discards "/." before it even looks
at the file.  It always does that.  This is not an inconsistancy;
on the contrary, Emacs is treating "/." in a consistent way
where other programs treat it specially.

That's not to say that what Emacs does is necessarily better.
But I don't want to try to change it.

Re: file-attributes inconsistent w. stat when .. or . symlinked

[Kevin Rodgers]

Richard Stallman wrote:

> What's happening is that Emacs discards "/." before it even looks
> at the file.  It always does that.  This is not an inconsistancy;
> on the contrary, Emacs is treating "/." in a consistent way
> where other programs treat it specially.


[look of surprise]

Emacs handles "/." specially, by stripping it.  If it was consistent, 
"/path/to/foo/." would be handled the same way as "/path/to/foo/bar".


> That's not to say that what Emacs does is necessarily better.
> But I don't want to try to change it.

[sigh]


-- 
Kevin Rodgers

Re: file-attributes inconsistent w. stat when .. or . symlinked

[Richard Stallman]

    Emacs handles "/." specially, by stripping it.

That's true.  My point is that Emacs consistently strips `/.' in all
operations.