bug#724: marked as done (Processed: another w32 bug)

[Emacs bug Tracking System]

Your message dated Sat, 20 Dec 2008 23:33:41 +0800
with message-id <494D1055.5030508@gnu.org>
and subject line Re: Crash opening UNC file.
has caused the Emacs bug report #719,
regarding Processed: another w32 bug
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
719: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=719
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: Processed: another w32 bug
>
>
>
>
> Date: 
>
> Fri, 15 Aug 2008 10:48:10 +0300
>
>
>
>
> > Date: Thu, 14 Aug 2008 17:50:05 -0700
> > From: don@donarmstrong.com (Emacs bug Tracking System)
> > Cc: Emacs Bugs <bug-gnu-emacs@gnu.org>, w32 #719 <don@donarmstrong.com>
> > 
> > Processing commands for control@emacsbugs.donarmstrong.com:
> > 
> > > reassign 719 emacs,w32
> > bug#719: Crash opening UNC file
> > Warning: Unknown package 'w32'
> > bug reassigned from package `emacs' to `emacs,w32'.
>
> Why, Jason?  This problem is specific to Cygwin, UNC file names work
> in the native w32 build.
>
> If we want to distinguish between Cygwin and the rest of Posix
> platforms, I suggest to create a new category "cygwin" and assign this
> bug to it.
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: Crash opening UNC file.
>
>
>
>
> Date: 
>
> Sat, 20 Dec 2008 23:33:41 +0800
>
>
>
>
> User-agent: 
>
> Thunderbird 2.0.0.18 (Windows/20081105)
>
>
>
>
> This turned out to be a bug in expand-file-name triggered by the project 
> file searching code in rails.el.
>
> A simple way to reproduce the bug was:
>
> (expand-file-name "//server/path/../../../")
>
> which caused an assertion failure on Windows.
>
> I have checked in a fix.
>
>
>
> --- End Message ---