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 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline 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