delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |