headers
Paul Foley | 16 Jun 07:11
X-Face

DIRECTORY bugfix

Calling DIRECTORY fails where there are broken symlinks in the
directory.

-- 
Tact is the ability to tell a man he has an open mind when he has a
hole in his head.

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Index: code/filesys.lisp
===================================================================
RCS file: /project/cmucl/cvsroot/src/code/filesys.lisp,v
retrieving revision 1.104
diff -u -r1.104 filesys.lisp
--- code/filesys.lisp	10 Sep 2007 16:25:00 -0000	1.104
+++ code/filesys.lisp	16 Jun 2008 05:06:35 -0000
@@ -1099,7 +1099,9 @@
 					   :directory))
 				  (concatenate 'string name "/")
 				  name)))
-		    (if truenamep (truename name) (pathname name))))
+		    (if truenamep
+			(handler-case (truename name) (error () (pathname name)))
+			(pathname name))))
 	      (sort (delete-duplicates results :test #'string=) #'string<)))))
(Continue reading)

Permalink | Reply |
headers
Madhu | 16 Jun 10:22

Re: DIRECTORY bugfix

Helu

* Paul Foley <m24p7urme9.fsf <at> mycroft.actrix.gen.nz> :
Wrote on Mon, 16 Jun 2008 17:15:10 +1200:

| Calling DIRECTORY fails where there are broken symlinks in the
| directory.

I had always thought this was a feature: specifying truenamep would
match behaviour of CL:TRUENAME, which would signal an error if the
target was non-existant.

[This is not an objection to the patch, but I _was_ using this in
some handlers to do the equivalent of 
	 `find -type l ! -xtype f ! -xtype d'  (find dangling symlinks)
but in all other cases I expect the handler in my compatibility layer
will not be called.]

--
Madhu
Permalink | Reply |
headers
Paul Foley | 16 Jun 13:49
X-Face

Re: DIRECTORY bugfix

On Mon, 16 Jun 2008 13:52:16 +0530, Madhu  wrote:

> Helu
> * Paul Foley <m24p7urme9.fsf <at> mycroft.actrix.gen.nz> :
> Wrote on Mon, 16 Jun 2008 17:15:10 +1200:

> | Calling DIRECTORY fails where there are broken symlinks in the
> | directory.

> I had always thought this was a feature: specifying truenamep would
> match behaviour of CL:TRUENAME, which would signal an error if the
> target was non-existant.

I don't think DIRECTORY should error here.  I'm not sure what the
right thing is, though (maybe it should just ignore broken links
altogether?  They're not really existing files, after all...)

> [This is not an objection to the patch, but I _was_ using this in
> some handlers to do the equivalent of 
> 	 `find -type l ! -xtype f ! -xtype d'  (find dangling symlinks)

How does it do that?  It just signals an error and doesn't return
anything.  ISTM you need to do (directory ... :truenamep nil) and try
calling truename on the results, or something...

--

-- 
Tact is the ability to tell a man he has an open mind when he has a
hole in his head.

(setq reply-to
(Continue reading)

Permalink | Reply |
headers
Madhu | 16 Jun 15:50

Re: DIRECTORY bugfix

* Paul Foley <m2wskpr44q.fsf <at> mycroft.actrix.gen.nz> :
Wrote on Mon, 16 Jun 2008 23:49:41 +1200:

| On Mon, 16 Jun 2008 13:52:16 +0530, Madhu  wrote:
|> I had always thought this was a feature: specifying truenamep would
|> match behaviour of CL:TRUENAME, which would signal an error if the
|> target was non-existant.
|
| I don't think DIRECTORY should error here.  I'm not sure what the
| right thing is, though (maybe it should just ignore broken links
| altogether?  They're not really existing files, after all...)

IME all interesting uses of CMUCL's DIRECTORY needed to use :TRUENAMEP
NIL, i.e. invoke non ANSI behaviour [but see below for a pathological
exception]

|> [This is not an objection to the patch, but I _was_ using this in
|> some handlers to do the equivalent of
|> 	 `find -type l ! -xtype f ! -xtype d'  (find dangling symlinks)
|
| How does it do that?  It just signals an error and doesn't return
| anything.  ISTM you need to do (directory ... :truenamep nil) and try
| calling truename on the results, or something...

You're right of course, and I do need to use a wrapper that does exactly
that.  But in this one use case I wanted to note, I used vanilla
DIRECTORY with TRUENAMEP T.  The function FIX-DANGLING-SYMLINKS caught
the file error and offered some restarts to remove the file and fix it
(including by hand), and then restarted the call to DIRECTORY --- the
idea was just to correct all dangling symlinks, so the call to directory
(Continue reading)

Permalink | Reply |
headers
Raymond Toy (RT/EUS | 18 Jun 18:11

Re: DIRECTORY bugfix

Madhu wrote:
> * Paul Foley <m2wskpr44q.fsf <at> mycroft.actrix.gen.nz> :
> Wrote on Mon, 16 Jun 2008 23:49:41 +1200:
> 
> | On Mon, 16 Jun 2008 13:52:16 +0530, Madhu  wrote:
> |> I had always thought this was a feature: specifying truenamep would
> |> match behaviour of CL:TRUENAME, which would signal an error if the
> |> target was non-existant.
> |
> | I don't think DIRECTORY should error here.  I'm not sure what the
> | right thing is, though (maybe it should just ignore broken links
> | altogether?  They're not really existing files, after all...)
> 
> IME all interesting uses of CMUCL's DIRECTORY needed to use :TRUENAMEP
> NIL, i.e. invoke non ANSI behaviour [but see below for a pathological
> exception]
> 
> |> [This is not an objection to the patch, but I _was_ using this in
> |> some handlers to do the equivalent of
> |> 	 `find -type l ! -xtype f ! -xtype d'  (find dangling symlinks)
> |
> | How does it do that?  It just signals an error and doesn't return
> | anything.  ISTM you need to do (directory ... :truenamep nil) and try
> | calling truename on the results, or something...
> 
> You're right of course, and I do need to use a wrapper that does exactly
> that.  But in this one use case I wanted to note, I used vanilla
> DIRECTORY with TRUENAMEP T.  The function FIX-DANGLING-SYMLINKS caught
> the file error and offered some restarts to remove the file and fix it
> (including by hand), and then restarted the call to DIRECTORY --- the
(Continue reading)

Permalink | Reply |
headers
Madhu | 19 Jun 22:58

Re: DIRECTORY bugfix


  |Date: Wed, 18 Jun 2008 12:11:26 -0400
  |From: "Raymond Toy (RT/EUS)" <raymond.toy <at> ericsson.com>
  |
  |> |> [This is not an objection to the patch, but I _was_ using this
  |> |> in some handlers to do the equivalent of `find -type l !
  |> |> -xtype f ! -xtype d' (find dangling symlinks)
  |> |
  |> | How does it do that?  It just signals an error and doesn't
  |> | return anything.  ISTM you need to do (directory ... :truenamep
  |> | nil) and try calling truename on the results, or something...
  |
  |Given the previous discussions, I'm inclined NOT to change
  |DIRECTORY.

I think DIRECTORY could use some cleaning up, [No I'm not sure how
best to do it.] -- presently it does not scale at all: Lynn Quam was
having problems and posted a speedup 2008-Jun-5 Message-ID
<200806051624.m55GOeBZ017042 <at> rugby.localdomain>

  |And given Madhu's use of directory, perhaps there should be some
  |kind of directory mapping function that calls a user supplied
  |function on each file as the file is processed so you don't have to
  |restart the call to directory from the beginning on each error.

I didn't emphasise that this use case was pathological, and I almost
always found TRUENAMEP NIL to be essential when dealing with UNIX
filesystem with symlinks.

The problem is of course that TRUENAME gets called inside a lambda
(Continue reading)

Permalink | Reply |
headers
Raymond Toy (RT/EUS | 19 Jun 23:34

Re: DIRECTORY bugfix

Madhu wrote:
>   |Date: Wed, 18 Jun 2008 12:11:26 -0400
>   |From: "Raymond Toy (RT/EUS)" <raymond.toy <at> ericsson.com>
>   |
>   |> |> [This is not an objection to the patch, but I _was_ using this
>   |> |> in some handlers to do the equivalent of `find -type l !
>   |> |> -xtype f ! -xtype d' (find dangling symlinks)
>   |> |
>   |> | How does it do that?  It just signals an error and doesn't
>   |> | return anything.  ISTM you need to do (directory ... :truenamep
>   |> | nil) and try calling truename on the results, or something...
>   |
>   |Given the previous discussions, I'm inclined NOT to change
>   |DIRECTORY.
> 
> I think DIRECTORY could use some cleaning up, [No I'm not sure how
> best to do it.] -- presently it does not scale at all: Lynn Quam was
> having problems and posted a speedup 2008-Jun-5 Message-ID
> <200806051624.m55GOeBZ017042 <at> rugby.localdomain>

His version has been checked in (with a minor change).

> 
>   |And given Madhu's use of directory, perhaps there should be some
>   |kind of directory mapping function that calls a user supplied
>   |function on each file as the file is processed so you don't have to
>   |restart the call to directory from the beginning on each error.
> 
> 
> The problem is of course that TRUENAME gets called inside a lambda
(Continue reading)

Permalink | Reply |

Gmane