Message-ID: <3999A16F.F8809412@softhome.net>
Date: Tue, 15 Aug 2000 22:00:47 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: Patch: open() adjustment for symlinks
References: <39998D7D DOT 70F85B9E AT softhome DOT net> <5137-Tue15Aug2000223737+0300-eliz AT is DOT elta DOT co DOT il>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> Too many "changed behavior" entries are not very useful (what will you
> write next time when the behavior is changed?).  

Hmm, haven't thought about that.

>   @findex open AT r{, accepts @code{O_NOLINK} and @code{O_NOFOLLOW} flags}

Will change that. Also, it could be cool if this entry says that open()
supports symlinks now... Maybe the following will do there?

@findex open AT r{, accepts @code{O_NOLINK} and @code{O_NOFOLLOW} flags}
@findex open AT r{, supports symlinks}

> >  int
> >  open(const char* filename, int oflag, ...)
> >  {
> >    int fd, dmode, bintext, dont_have_share;
> > +  char real_name[FILENAME_MAX + 1];
> >    int should_create = (oflag & (O_CREAT | O_EXCL)) == (O_CREAT | O_EXCL);
> >
> > +  /* Solve symlinks and honor O_NOLINK flag  */
> > +  if (oflag & O_NOLINK)
> > +      strcpy(real_name, filename);
> > +  else
> > +  {
> > +     if (!__solve_symlinks(filename, real_name))
> > +        return -1; /* errno from from __solve_symlinks() */
> > +  }
> 
> Bother.  __solve_symlinks doesn't have an FSEXT, does it?  

No, it doesn't right now. I can't think of any reasonable reason
why user should intercept symlink resolving, any ideas there?

> So what
> does a file extension do if it wants to catch this new code?

FSEXT open handler will catch that later, in _open(), with symlinks
resolved. Is there anything wrong with this setup? Am I missing something?

> Also note that the special precautions that `open' takes not to fail
> in the case of a file that's open by another program on Windows, in
> this fragment:
[...]
> aren't in __solve_symlinks, sop `open' might fail inside
> __solve_symlinks in these cases.

In fact, readlink() is affected there, __solve_symlinks() does
all its job through it. I'll post a patch which adds this 
precaution there too.

> Why not use `basename'?  

Because I didn't know about its existence. I will switch to it.

> Don't you need to handle the case of "d:foo"?

I don't think so, because 'd:' cannot be a symlink in DOS.

> (If you do use `basename', you need to make a stub for it.)

Will do.

> Please put ELOOP inside @code{}.

Will fix.

Thanks for comments,
Laurynas