Messages in this thread | | | Subject | Re: JFS default behavior (was: UTF-8 in file systems? xfs/extfs/etc.) | From | Valdis.Kletnieks@vt ... | Date | Mon, 16 Feb 2004 12:58:40 -0500 |
| |
On Mon, 16 Feb 2004 18:26:47 +0100, Pascal Schmidt said: > On Mon, 16 Feb 2004 17:10:23 +0100, you wrote in linux.kernel: > > >> file and created another with the same name between you calling creat() > >> and doing the readdir(). What would be the use of this, anyway? > > How does the shell do 'echo foo*'? > > I fail to see the connection with creat() followed by readdir(). The shell > is surely not expecting the names that follow from the glob expansion to > have any relationship with previous shell operations
Oh?
% rm * % touch foo1 bar1 # this calls creat() or open() or similar % touch foo2 bar2 # as will this... % echo foo* # and this will do a readdir(), presumably
Do you have any expectations what the echo will do? Obviously the glob DOES have a relationship with previous shell operations.
The point is that *if* we assume that glibc is going to do some magic conversion when creating a file, we are assuming that glibc will *always* keep the conversion hidden. No matter what. Because the user now has expectations of what that file was called when he created it - the string he passed to open()/creat(). If what gets handed to the kernel is something different, we have to make sure that the user never finds out about it.
And if there's special iso8859-* chars in the filename, this means that the magic handwave to convert to utf-8 inside glibc will either have to do it in-place (mangling the user-supplied filename, and bad karma) or it gets to call malloc() to get a work space (can't use a 'static char[MAXPATHLEN]', that's not thread-safe.
This gets *very* interesting if the malloc() fails.. ;) [unhandled content-type:application/pgp-signature] | |