[M3devel] symlink grief?

Jay K jay.krell at cornell.edu
Fri Sep 3 23:00:52 CEST 2010


Clarification: There were changes at both levels. The toplevel ones maybe all unnecessary. I'll maybe look at this more but I also suspect it is ok now. Another approach would be to avoid stat altogether here, in rmrec. One can deduce the type by calling unlink and/or rmdir & checking the error. Or just rewrite rmrec in C..

 - jay/phone

> Date: Fri, 3 Sep 2010 14:38:25 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] symlink grief?
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3.
> > How about:
> >
> > PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER =
> >   VAR statBuf: Ustat.struct_stat;
> >   BEGIN
> >     IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s,   
> > ADR(statBuf)) < 0 THEN
> >       RETURN -1;
> >     END;
> >     status.type := FilePosix.FileTypeFromStatbuf(statBuf);
> >     (* Could make following assignments conditional on type: *)
> >     status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL);
> >     status.size := statBuf.st_size;
> >     IF status.size < 0L THEN RETURN -1 END;
> >     RETURN 0
> >   END CStatus;
> 
> Could be worth a try,
> 
> Olaf
> 
> >
> > I can look again, *maybe* rmrec can avoid calling here.
> > Though probably the best way to achieve that is by writing two   
> > independent versions in C.
> > I think the Modula-3 file system libraries are just too keen on   
> > calling stat, which fails
> > for dangling symlinks.
> >
> >  - Jay
> >
> > ----------------------------------------
> >> Date: Fri, 3 Sep 2010 13:10:51 +0200
> >> From: wagner at elegosoft.com
> >> To: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] symlink grief?
> >>
> >> Symbolic links usually `just work'.
> >> If you have changed stat to lstat for all use cases, that will of
> >> course cause problems. I thought your changes were local to the
> >> rmrec implementation for quake. Aren't they?
> >>
> >> If not, it will be better to revert them.
> >>
> >> Olaf
> >>
> >> PS: Windows NTFS does support symbolic links, too, though I've probably
> >> never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link
> >>
> >> Quoting Jay K :
> >>
> >> >  +++ /cm3/bin/cm3  -ship -DROOT=/home/jay/dev2/cm3 +++
> >> > --- shipping from I386_LINUX ---
> >> >
> >> > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1:
> >> > quake runtime error: unable to create directory "/cm3": errno=17
> >> >
> >> > --procedure--  -line-  -file---
> >> > make_dir           --
> >> >                     1    
> >> /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP
> >> >
> >> > Fatal Error: package build failed
> >> >  *** execution of [,
> >> >
> >> >
> >> >
> >> > /cm3 is a symlink to /home/jay/cm3
> >> > They both exist.
> >> > /home/jay/cm3 is a directory.
> >> >
> >> > I predict no good answers here.
> >> >  - a code base that historically used stat, that I changed to lstat.
> >> >
> >> > I think maybe I should put it back to stat.
> >> > And maybe come up with new functions for fs_rmrec to use.
> >> >
> >> > Wild guess... we have code like:
> >> >
> >> >
> >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN =
> >> >   VAR s: File.Status;
> >> >   BEGIN
> >> >     TRY
> >> >       s := FS.Status (path);
> >> >       RETURN (s.type = FS.DirectoryFileType);
> >> >     EXCEPT OSError.E =>
> >> >       RETURN FALSE;
> >> >     END;
> >> >   END IsDirectory;
> >> >
> >> >
> >> > Maybe the right thing is to mimic Posix and allow code like:
> >> >
> >> >
> >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN =
> >> >   VAR s: File.Status;
> >> >   BEGIN
> >> >     TRY
> >> >       s := FS.LinkStatus (path);
> >> >       RETURN (s.type = FS.SymblicLinkFileType);
> >> >     EXCEPT OSError.E =>
> >> >       RETURN FALSE;
> >> >     END;
> >> >   END IsDirectory;
> >> >
> >> > or such?
> >> >
> >> > Not sure it is needed.
> >> >
> >> > Or FS.StatusNoLinkResolve? Is that clearer?
> >> >
> >> > There are a few basic problems here:
> >> >   - The "Modula-3 code base" has been written I assume without
> >> > symlinks in mind. ??
> >> >   - I don't have symlinks in mind, much at all, since I'm usually
> >> > not on a system with them.
> >> >   I don't have a mental model of how to program with them, etc.
> >> >   Maybe some short document I can read and memorize?
> >> >
> >> >
> >> >  - Jay
> >> >
> >>
> >>
> >>
> >> --
> >> Olaf Wagner -- elego Software Solutions GmbH
> >> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> >> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >>
> >
> 
> 
> 
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100903/6ec7f421/attachment-0002.html>


More information about the M3devel mailing list