On Mar 15 06:49, Brian Dessent wrote:
> Anyway, the attached is the result of what happened when I started with
> the Cygwin code and whittled it down. It fixes the bug in the
> grandparent of this email where it was reading the Win32 path out of a
> shortcut that didn't have an ITEMIDLIST, and it
Corinna Vinschen wrote:
> Yuk. I guess it would help a lot to reproduce path.cc:check_shortcut(*)
> in utils as close as possible. Afaics it doesn't use any code which
> would be restricted to Cygwin, except for the call to
> mount_table->conv_to_posix_path in the posixify method.
I started dow
Corinna Vinschen wrote:
> Urgh. MAX_PATH is defined with trailing 0, SYMLINK_MAX is defined
> without trailing 0 (like NAME_MAX). You should better change the
> SYMLINK_MAX stuff back, afaics...
D'oh! 'Kay.
On Mar 11 10:07, Brian Dessent wrote:
> Corinna Vinschen wrote:
>
> > 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...
>
> Oh, I wasn't even thinking of that... the reason I used
Corinna Vinschen wrote:
> 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...
Oh, I wasn't even thinking of that... the reason I used MAX_PATH + 1 was
because earlier I had written
+
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.
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 curren
On Mar 10 21:10, Corinna Vinschen wrote:
> On Mar 10 15:08, Christopher Faylor wrote:
> > However, I don't understand what a mingw app would see when it is started
> > from Cygwin now. What would a standard windows app think that its cwd would
> > be if it's cd'ed deep into a 32K long path.
>
> R
On Mar 10 15:08, Christopher Faylor wrote:
> However, I don't understand what a mingw app would see when it is started
> from Cygwin now. What would a standard windows app think that its cwd would
> be if it's cd'ed deep into a 32K long path.
Right now, Cygwin copies its CWD into the user paramet
On Mon, Mar 10, 2008 at 11:34:44AM +0100, Corinna Vinschen wrote:
>On Mar 9 19:20, Christopher Faylor wrote:
>> On Sun, Mar 09, 2008 at 08:55:09PM +0100, Corinna Vinschen wrote:
>> >On Mar 9 11:03, Brian Dessent wrote:
>> >> Christopher Faylor wrote:
>> >>
>> >> > I guess I misunderstood. I tho
On Mar 9 17:30, Brian Dessent wrote:
> Corinna Vinschen wrote:
> > The problem is that the cwd is stored as UNICODE_STRING with a
> > statically allocated buffer in the user parameter block. The
> > MaximumLength is set to 520. SetCurrentDirectory refuses to take paths
> > longer than that. In
On Mar 9 19:20, Christopher Faylor wrote:
> On Sun, Mar 09, 2008 at 08:55:09PM +0100, Corinna Vinschen wrote:
> >On Mar 9 11:03, Brian Dessent wrote:
> >> Christopher Faylor wrote:
> >>
> >> > I guess I misunderstood. I thought that the current working directory
> >> > could be derived through
Corinna Vinschen wrote:
> The problem is that the cwd is stored as UNICODE_STRING with a
> statically allocated buffer in the user parameter block. The
> MaximumLength is set to 520. SetCurrentDirectory refuses to take paths
> longer than that. In theory it would be possible to define a longer
On Sun, Mar 09, 2008 at 08:55:09PM +0100, Corinna Vinschen wrote:
>On Mar 9 11:03, Brian Dessent wrote:
>> Christopher Faylor wrote:
>>
>> > I guess I misunderstood. I thought that the current working directory
>> > could be derived through some complicated combination of Nt*() calls.
>>
>> I c
On Mar 9 11:03, Brian Dessent wrote:
> Christopher Faylor wrote:
>
> > I guess I misunderstood. I thought that the current working directory
> > could be derived through some complicated combination of Nt*() calls.
>
> I could be wrong here but the way I understood it, there is no concept
> of
Christopher Faylor wrote:
> I guess I misunderstood. I thought that the current working directory
> could be derived through some complicated combination of Nt*() calls.
I could be wrong here but the way I understood it, there is no concept
of a working directory at the NT level, that is somethi
On Sun, Mar 09, 2008 at 04:14:40PM +0100, Corinna Vinschen wrote:
>On Mar 9 10:38, Christopher Faylor wrote:
>> On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote:
>> >Bash as well as tcsh, as well as zsh (and probbaly pdksh, too) create an
>> >environment variable $PWD. Maybe Cygwi
On Mar 9 10:38, Christopher Faylor wrote:
> On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote:
> >Bash as well as tcsh, as well as zsh (and probbaly pdksh, too) create an
> >environment variable $PWD. Maybe Cygwin should create $PWD for native
> >apps if it's not already available
On Sun, Mar 09, 2008 at 10:28:06AM +0100, Corinna Vinschen wrote:
>Hi Brian,
>
>Thanks for your patch. I have a few nits, sorry.
>
>On Mar 8 20:13, Brian Dessent wrote:
>> Index: cygcheck.cc
>> ===
>> RCS file: /cvs/src/src/winsup/ut
On Mar 9 05:02, Brian Dessent wrote:
> Corinna Vinschen wrote:
>
> > Now that you mention it... did you see the comment in path.cc, line 3112ff?
> > There's a good chance that Windows shortcuts are not capable of long path
> > names. I didn't test it so far, but it would be certainly better for
Corinna Vinschen wrote:
> Now that you mention it... did you see the comment in path.cc, line 3112ff?
> There's a good chance that Windows shortcuts are not capable of long path
> names. I didn't test it so far, but it would be certainly better for
> readlink to use the POSIX path in the symlink
On Mar 9 03:32, Brian Dessent wrote:
> Corinna Vinschen wrote:
>
> > > > I'm wondering if you would like to tweak the readlink functions, too.
> > > > Cygwin shortcuts can now have the path name appended to the actual
> > > > shortcut data. This hack was necessary to support pathnames longer tha
Corinna Vinschen wrote:
> > > I'm wondering if you would like to tweak the readlink functions, too.
> > > Cygwin shortcuts can now have the path name appended to the actual
> > > shortcut data. This hack was necessary to support pathnames longer than
> > > 2000 chars. See the comment and code in
On Mar 9 01:40, 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.
>
> Regardless of this patch, path.cc:rel_vconcat() currently use
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.
Regardless of this patch, path.cc:rel_vconcat() currently uses
GetCurrentDirectory() to resolve relative paths.
Hi Brian,
Thanks for your patch. I have a few nits, sorry.
On Mar 8 20:13, Brian Dessent wrote:
> Index: cygcheck.cc
> ===
> RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
> retrieving revision 1.97
> diff -u -p -r1.97 cygcheck.
Christopher Faylor wrote:
> It looks like yo can still unindent this by changing the == to !=, putting
> the temppath under that and keeping all of the if's at the same level:
Oh, I see now what you mean.
> If the if block is that small, then I think I'd prefer just one comment
> at the beginni
27 matches
Mail list logo
