X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
X-Authenticated:	#27081556
X-Provags-ID:	V01U2FsdGVkX1/4N7Zc/Xb4o9KxpE4Zx0XkCmbDEYlhguxqgg/d3i
	4gom3E3QLZfrHK
From:	Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To:	djgpp-workers AT delorie DOT com
Subject:	About the syntax of the change file for djtar
Date:	Tue, 6 Nov 2007 18:25:42 +0100
User-Agent:	KMail/1.9.5
MIME-Version:	1.0
Message-Id:	<200711061825.42739.juan.guerrero@gmx.de>
X-Y-GMX-Trusted:	0
Reply-To:	djgpp-workers AT delorie DOT com

While I was porting lcms 1.17 I had some difficulty creating a fnchange.lst for
that port to be able to extract the original archive using djtar in a way that
I wanted.  The archive contains file names like "sRGB Color Space Profile.icm".
It was my intention to create a fnchange.lst file that renamed file names
containing space characters in a way prefered by me.  Unfortunately this was
not possible because djtar uses the space character as separator character
between the old file name string and the new file name string in fnchange.lst.
IMHO it was a mistake to choose a valid file name character, either in posix
and in Windows, as a separator for old and the new file name strings.  Please
note that I am completely aware that djtar is capable to replace space
characters by a valid SFN characters if the OS has no LFN support.  The point
is that it is not possible for the user to control the output file name if the
input file name contains space characters.  May be I am wrong but it seems to
me that this can only be solved by replacing the current separator character
by one that is certainly an invalid file name character in both posix and
Windows environment.  The `|' (pipe) character may be such a choice.  No matter
what ever is choosen it will brake backward compatibility.  All fnchange.lst
files produced for djgpp ports will no longer work.  Of course, in new ports
this can be easily fixed.  The question is if this issue shall be fixed/modified
or not.  May be that some one else has a solution that does not brake the old
fnchange.lst files around.

Regards,
Juan M. Guerrero

- Raw text -