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