From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10302120015.AA24278@clio.rice.edu>
Subject:	Re: fix for copyrite.c[c]/copyrite.pl
To:	cyp AT fb14 DOT uni-mainz DOT de (Cyrus Patel)
Date:	Tue, 11 Feb 2003 18:15:35 -0600 (CST)
Cc:	djgpp-workers AT delorie DOT com (DJGPP developers)
In-Reply-To:	<3E4931A3.2855.C979899C@localhost> from "Cyrus Patel" at Feb 11, 2003 05:22:22 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> > > btw, in an NT (2K) VDM however I saw 'file not found' errors for
> > > stat() when the pathlen > 64. Shouldn't LFNizing have avoided that?
> > 
> > No, LFN on W2K/XP still have path length limits on the short name
> > equivalents.  It shows how it works under the hood ...
> 
> Given copyrite.c uses only dir/file names that were obtained with 
> readdir(), isn't it working exclusively in the LFN "name space"?

No, Win2K/XP is internally using short names and doing conversions.
But if you install in a directory relatively high up in the disk
structure it's not a problem ... Or use SUBST

Long paths cause problems burning to CDs too :-)

> > There is code in DJGPP to work with this - but you must use relative
> > paths instead of absolute paths when deep in the directory structure.
> 
> Do you mean relative in the sense that a dirname without a path
> still needs to be prefixed with a ".\"?

Some things work, other things haven't been hacked to work.  It's a
mine field.  It's best just not to go deep or things break.

> > I think the last block should be handled by manual edits, 
> 
> Well, do you have someone in mind who is going to go through and 
> inspect/edit each file manually? :)

I might modify your program to print a list and look at them.  Some
may have multiple CVS revisions, which means they should not be
changed.

I suspect this list is small.

- Raw text -