Mail Archives: djgpp-workers/1999/08/25/10:45:55
> 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.
- Raw text -