[comp.sys.ti.explorer] problem with copy-file - SunOS 4.0 in the namespace.

acuff@SUMEX-AIM.STANFORD.EDU (Richard Acuff) (06/01/89)

Here's an SPR I sent in about Explorers and SunOS 4.0.  The patch is for
Explorer rel 5, but I think it'll work on earlier versions as well.  However,
you'll also want to make sure your Sun is set up correctly in the namespace.
From the looks of your message, it may not be.

	-- Rich

DATE-TIME   : 19-Oct-88 21:27:34
PRIORITY    : H     (H)igh (M)edium (L)ow
TYPE        : B     (B)ug  (D)esign (M)anual
MACHINE-TYPE: M     (E)xplorer (M)icroExplorer

DESCRIPTION-OF-PROBLEM:
   (FS:DIRECTORY-LIST "ksl:/a/acuff/foobar/*") where the string denotes a
   non-existant directory on a Sun running their OS 4.0 returns a strange
   value instead of erroring as it should.  The returned value is:

   ((NIL
      :PATHNAME
      #FS::UNIX-UCB-PATHNAME "KSL.Stanford.edu: /a/acuff/foobar/*")
    (#FS::UNIX-UCB-PATHNAME "KSL.Stanford.edu: /a/acuff/foobar/found"
     :DIRED-ECHO "/"
     :LENGTH-IN-BYTES NIL))

   This error can cause hard to figure out problems in a number of
   circumstances.

WORK-AROUND:
   Sun seems to have changed what comes back in the data stream from a LIST
   of a non-existant directory from an empty line to the file name followed
   by " not found".  The following one-line fix checks for this case (RDA:):

   FS:
   (DEFMETHOD (FTP :case :directory-list-from-ftp :bsd4.2) (pathname ftp stream fast?
							    &aux data-stream line entry entry-list
							    in-subdirectory total-line-p open-name directory-name)
     (let ((sys:*new-line-delimiter* '(#\newline #\linefeed))) ;01-27-88 DAB
       (declare (special sys:*new-line-delimiter* ))
       (BLOCK bsd4.2
       (LOOP
	 ;; open-name is equivalent to parameter pathname considering directory link translation
	 ;; directory-name is the pathname actually passed across the control connection
	 (SEND ftp :open
	       (PROG1 (SETF directory-name (dir-pathstring-for-ftp (SETF open-name (OR *ftp-directory-link* pathname))))
		      (SETF directory-name (parse-pathname directory-name nil pathname)))
	       ;; Unix nlist returns a null listing for both nonexistant and empty directories
	       ;; Don't use nlist to speed up the listing on a recursive entry, or empty directories will appear as nonexistant
	       :list)
	 ;; workaround a Unix 425 bug which seems to go away on the second open attempt
	 (UNLESS (AND (EQ 425 (SEND ftp :reply-code))
		      (SEARCH "Can't create data socket" (SEND ftp :reply-string))
		      (SEARCH "Address already in use" (SEND ftp :reply-string)))
	   (RETURN)))
       (UNLESS (or (ftp-unfavorable (SEND ftp :reply-code))
		   (not (SEND ftp :data-connection)))   ;03-03-88 DAB
	 (SETF data-stream (SEND ftp :data-connection))
	 ;; work around Unix bug of giving favorable status for a nonexistant directory
	 (WHEN (or (NULL (SETF line (READ-LINE data-stream nil)))
		   (search " not found" line))	;RDA: Work with SunOS 4.0
	   (COND
	     ;; if FTP list command on parent directory, then directory not found
	     ((OR *ftp-recursive-directory-list-from-ftp*
		  (NOT (pathname-equal directory-name open-name)))
	      (SETF (SEND ftp :reply-code) 450)
	      (SETF (SEND ftp :reply-string) (FORMAT nil "Directory not found for ~a" pathname))
	      (RETURN-FROM bsd4.2 nil))
	     ;; if FTP list command on root directory, then file not found 
	     ((EQL :root (SEND pathname :directory))
	      (RETURN-FROM bsd4.2 nil))
	     ;; must check existence of parent directory to make decision
	     (t (LET ((*ftp-recursive-directory-list-from-ftp* t))
		  (SEND ftp :close)
		  (SEND self :directory-list-from-ftp :bsd4.2
			(SEND pathname :directory-pathname-as-file) ftp stream fast?)
		  ;; reply code is set by the recursive call
		  (RETURN-FROM bsd4.2 nil)))))
	 ;; work around Unix bug of giving favorable status for a protected directory
	 (WHEN (SEARCH (STRING-APPEND (SEND directory-name :string-for-host) " unreadable") line)
	   (SETF (SEND ftp :reply-code) 450)
	   (SETF (SEND ftp :reply-string) (FORMAT nil "~a: Permission denied" pathname))
	   (RETURN-FROM bsd4.2 nil))
	 ;; when recursively entered, we were only checking the existance of the parent directory, so exit.
	 ;; (Note also that Unix will chase links with the NLST comand, so we don't have to worry about links.)
	 (IF *ftp-recursive-directory-list-from-ftp*
	     (RETURN-FROM bsd4.2 nil)
	     (add-directory-stream stream data-stream))
	 (MULTIPLE-VALUE-SETQ (entry in-subdirectory total-line-p)
	   (bsd4.2-directory-line-parse pathname directory-name open-name line fast? in-subdirectory))
	 ;; They gave us /d1/d2.  Unix lists d2 if it is a directory.
	 ;; We considered d2 as the file spec and thus don't match anything if d2 is a directory.
	 ;; Assumption is based on the fact that we saw the total line first (e.g. total n) when only a single file was requested.
	 (WHEN (AND total-line-p (pathname-equal directory-name open-name))
	   (RETURN-FROM bsd4.2 (LIST (LIST pathname :directory t))))
	 ;; Workaround Unix feature of not chasing the link path with the LIST command (and returning the link information instead),
	 ;; when we were listing the parent directory.  We throw out with a single entry, which needs its link chased.
	 (WHEN (AND (GETF (CDR entry) :link-to)
		    (NOT (pathname-equal directory-name open-name))
		    (pathname-equal (FIRST entry) directory-name))
	   (THROW :directory-link-error (LIST entry)))
	 (LOOP
	   (WHEN entry (PUSH entry entry-list))
	   (UNLESS (SETF line (READ-LINE data-stream nil))
	     (RETURN-FROM bsd4.2 entry-list))
	   (MULTIPLE-VALUE-SETQ (entry in-subdirectory total-line-p)
	     (bsd4.2-directory-line-parse pathname directory-name open-name line fast? in-subdirectory)))))))

TI Number: 8948 (supposed to be fixed in IP 3.41 (supercedes 3.30)
Submitter: Acuff

CUSTOMER-ID: 124

NAME       : Richard Acuff
LOCATION   : WR C101 Acuff
ADDRESS    : 
PHONE      : (415) 723-2225
NET-ADDRESS: Richard Acuff <Acuff@KSL.Stanford.EDU>

SOFTWARE-CONFIGURATION:

   With SYSTEM 5.9, MICRONET-COMM 5.5, BASIC-NAMESPACE 5.3, RPC 5.4,
   NFS 5.8, MACTOOLBOX 1.6, WINDOW-MX 5.15, MAC-PRINTER-TYPES 5.1, IP 3.29,
   NFS-SERVER 5.3, DECNET 1.38, Experimental KSL-PATCHES 2.0,  microcode 88,
   Band Name: 5.0(9B), KSL8 2.0, 17-Oct, Host: KSL-Mac-62

HARDWARE-CONFIGURATION:
   microExplorer,  Microcode MX-UCODE 88 for the Explorer Lisp Microprocessor

snicoud@ATC.BOEING.COM (Stephen Nicoud) (06/01/89)

   Date: 31 May 89 18:50:48 GMT
   From: usc!brand.usc.edu!venkat@bloom-beacon.mit.edu.ARPANET  (V. Venkat)
   Subject: problem with copy-file - SunOS 4.0 in the namespace.
   
   recently we updated our Sun to 4.0. since then copy-file to the SUN
   does not work. for eg: (copy-file "lm:junk.lisp" "sun:junk.lisp")
   returns
   --------------------------------------------------------------------------
   >>error: the object #<FS::LISPM-PATHNAME "SUN: USER; JUNK.LISP"># received
     a :PARSE-DIRECTORY-ENTRY message, which went unclaimed.
     The rest of the message was 
     (#<FS::LISPM-PATHNAME "SUN: USER; NOT FOUND.XLD#>"> "")
     While in the function SYS::FLAVOR-UNCLAIMED-MESSAGE 
                           <- SYS::INSTANCE-HASH-FAILURE <- FS::FTP-DIR-MERGE
   --------------------------------------------------------------------------
   i tried different combinations of directory names on the SUN,
   with the same result. needless to say, i have the same problems
   when trying to access the directory through dired. i'm using TCP/IP 2.77
   on explorer 3.2.
   Any clue will be appreciated.
   Will summarize to the net after this problem is fixed.
   
   V.V.

IP patch 3.41 fixes this problem.  I'm not sure what the corresponding
patch is for IP version 2.  I sent V. Venkat patch 3-43, and he reported
that it fixed the problem.

Steve

snicoud@ATC.BOEING.COM (Stephen Nicoud) (06/01/89)

I meant IP patch 3.41 not 3.43.