Re: JFS default behavior (was: UTF-8 in file systems? xfs/extfs/etc.)

[Valdis . Kletnieks]

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.. ;)

Attachment: pgp00000.pgp
Description: PGP signature