Re: [patch] cygcheck.cc update for cygpath()

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar 11 08:36, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > Given that Cygwin changes to support long path names, I don't really
> > like to see new code still using MAX_PATH and Win32 Ansi functions
> > in the utils dir.  I know that the Win32 cwd is always restricted to
> > 259 chars.  However, there *is* a way to recognize the current working
> > directory of the parent Cygwin application.
> 
> Here's an updated version of the patch.  It addresses the problem of
> resolving symlink targets relative to the dir of the link without a
> gratuitous Get/SetCurrentDirectory sequence by introducing
> cygpath_rel().  It does not yet address the issue of modernizing the
> symlink reading code, that will follow.
> 
> This patch still has two cases of MAX_PATH usage: one in a buffer that
> is used for GetCurrentDirectory(), so I don't see how making it larger
> there helps.  The second is in a static buffer for the dirname()
> helper.  I could simply make this one larger, however, the context where
> this dirname() is used is a filename that's used with CreateFile() so
> until that is plumbed to use WCHAR and \\?\ I don't really think it
> makes sense to use more than MAX_PATH.  I could update that instance of
> CreateFile, but the thing that provides the filename passed here is
> itself driven by GetFileAttributes(), so it would need to be updated
> too... and so on.  It looks like a lot of work to go completely
> longfile-clean here.

The patch looks basically ok with me.  Please check in.

Btw., you don't need to make the buffers MAX_PATH + 1.  MAX_PATH is
defined including the trailing NUL.  Existing code shows a lot of
irritation about this...


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat