Message-ID: From: Michel de Ruiter To: "'Eli Zaretskii'" Cc: "'DJGPP workers'" Subject: RE: ASCII 128+ in filenames Date: Wed, 25 Aug 1999 14:03:21 +0200 X-Mailer: Internet Mail Service (5.5.2448.0) Reply-To: djgpp-workers AT delorie DOT com > What happens if you install another codepage--do the codes of the > converted characters, and what they are converted into, change? I'll test that. I would think so but I hope not... > > Should we check for these things in (for > > instance) djtarx, unzip, tar, Emacs, etc.? > > I encountered this when unzipping files > > containing 128+ characters, actually. > What are the problems that this conversion causes? Well, the automatic filename conversion in djtarx, unzip and tar does not know that "filename" and "fîlenámé" will result in the same file. So if a zipfile contains both, the user has to rename it himself. Now that I think of it, this is the same as having both "filename" and "FILENAME", or "filename" and "filename.", so there is nothing new here. > Emacs 20 supports encoding of file names (with the same MULE > machinery that is used to encode and decode non-ASCII > characters). Perhaps if we understand the problems, we could > use this feature to help. How does Emacs determine whether two buffers are actually the same file? For instance: c:/path/filename k:/filename (SUBSTed) filename FILENAME filename filename. filename fîlenámé filename ../path/filename Maybe this is something that libc should/could handle, no? The files should have the same inode number, for instance... I don't have any real problems with it, but maybe this is another peculiarity of DOS that DJGPP should handle. We should at least be aware of it, that's why I brought this up. Groente, Michel.