Date: Thu, 28 Jun 2001 13:35:56 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Dan Nelson <dnelson AT emsphone DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: DJGPP under Windows 2000
In-Reply-To: <566b0935.0106271007.74fcc474@posting.google.com>
Message-ID: <Pine.SUN.3.91.1010628133531.12284M-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On 27 Jun 2001, Dan Nelson wrote:

> The only annoying one is the rename() routine doesn't work on
> 8.3-only network shares anymore; it tries to rename oldfile ->
> X$$djren$$.$$temp$$ -> newfile, and where win98 simply truncated the
> long name, w2k makes the call fail.
> The quick fix is to hexedit X$$djren$$.$$temp$$ to X$$djren.tmp.
> The long fix is to change the source in libc/ansi/stdio/_rename.c
> and rebuild libc.

As DJ said, please send the patches.

However, this problem is a manifestation of a limitation in the
current implementation of the long file name support in DJGPP: it
assumes that if long file names are supported by the OS, they are
available on all filesystems (a.k.a. drives).  In your case, it sounds
like the network software violates this assumption.  So I'd expect to
see more breakage with other system calls.  The telltale sign of such
problems is that some file-related operation fails with EINVAL.