bug#7971: Bug in libiconv?
. The alternative is to have this table stored in a file charset.alias; but then every package that includes the module 'localcharset' from gnulib (that is, libiconv, gettext, coreutils, and many others) will want to modify this file during make install. And this causes a lot of headaches to packaging systems. Therefore, on platforms which have widely used packaging systems (Linux, MacOS X, Cygwin), it's better to avoid the need for this file. Now I'm puzzled. If that's the case, why does libiconv request the charset.alias file on *any* other system than DARWIN7, VMS, and Windows? Especially on Linux? I optimized only the MacOS X, VMS, and Windows OSes. It would have been more work to optimize all versions of Solaris, FreeBSD, AIX, etc. in the same way. charset.alias is requested on Linux, even though it normally does not exist, so that packagers and users have a chance to modify the behaviour. I beg to keep this choice to Cygwin users as well. It will be empty by default as well. The supported codesets are documented in http://cygwin.com/cygwin-ug-net/setup-locale.html#setup-locale-charsetlist If some weird alias is required, the user can add it to charset.alias. That's the optimal solution. Even if Cygwin/newlib handles Windows codepage aliases in all places where it matters for Cygwin, there are still places where it matters for gnulib, coreutils, gettext. Since gnulib, coreutils and gettext are ported to Cygwin anyway, the ported versions should live happily in the Cygwin world. They get what the system defines, and the system is Cygwin, not Windows. Everything else can be added to charset.alias, if required. Neither libiconv nor gettext defines or undefines _WIN32 or __WIN32__. But they are prepared to either setting. Isn't that just covering a PEBKAC? I mean, there's no good reason to define -mwin32 on the command line and the libiconv configure certainly doesn't add it. Whoever squeezed a -mwin32 onto the GCC command line, or even defined -D__WIN32__ manually, deserves the result. But such a user will then write a mail to a mailing list, and it will take time for me (or someone else) to investigate and answer it. By writing #if (defined _WIN32 || defined __WIN32__) !defined __CYGWIN__ I avoid this potential problem. Ok. However, the other variation #if defined _WIN32 || defined __WIN32__ || defined __CYGWIN__ should be only used in very rare circumstances. Usually it just means that some unnecessary Windowism is used on Cygwin, and that there's probably a POSIXy equivalent. If not, kick us here on the list and we can discuss it. Thanks again for your reply and for the hint to the bug in libiconv's code. You're welcome and thanks for this fruitful discussion. I'm glad if we can find a well-working compromise for some of the problems, especially in the unfortunate UTF-16 case. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: mkdir -p and EROFS
On Oct 13 00:02, Paul Eggert wrote: Christopher Faylor writes: I'm just wondering if there is some kind of official coreutils policy here. Not for coreutils itself, no. However, the GNU coding standards make it clear that porting to systems like Cygwin is lower priority for the GNU project than porting to GNU/Linux. See http://www.gnu.org/prep/standards/html_node/System-Portability.html. I book a place for Cygwin in the other UNIX-like systems category, according to the third paragraph. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls when acl() is busy [was: ls slow on top-level directory]
On Jun 28 03:24, Eric Blake wrote: [bug-coreutils: posting this cygwin question upstream] Corinna Vinschen wrote: Along these lines, we had a short discussion on the developers list and we're wondering if it's necessary that ls prints this error message at all. The message is generated after a stat() already succeeded and a follow up acl() call returns -1. To say it with Dave Korn's words: ISTM that ls has all the information it should need to DTRT - a successful call to stat(), a return value of -1 from acl() and (I would hope that) errno has EACCES(*) from the ERROR_SHARING_VIOLATION return should let it deduce 'the file exists but is locked', shouldn't it? (*) actually EBUSY. Eric? Hmm - murky waters here. It would be a simple one-line fix to coreutils/lib/acl.c to ignore EBUSY as a non-error, and POSIX has no requirements per se that a failure of acl() should imply a failure of ls(1). Should a busy file be conservatively treated as having an ACL (designated with '+' in the mode string) or left alone without one (designated with ' ' in the mode string) when cygwin is unable to query Windows without blocking for an undue length of time? Right now, I'm almost leaning for a third option, and displaying '?' or some other character to mean unable to determine, but that I'd rather not do this. The output of ls is already complex enough and people having scripts munging ls output (well, just a thought...) would have a hard time to find the bug in their scripts. I think this is a corner case anyway, and it's pretty Cygwin/Windows related. The core problem is that on WIndows, some file metadata is locked together with the file data when a process locks a file exclusively. So, for instance, you can get the file size, but not the permissions, the ACL. The EBUSY only happens because stat() tries very hard to get *some* information about a file and returns a (mostly) valid stat record even if it couldn't determine all information. acl() on the other hand really needs access to the file to get the ACL. So stat() works, but acl() fails. Very unfortunate, I admit. However, IMHO, ls should be changed to just print no error message, if file_has_acl() returns -1 and errno is set to EBUSY, and the file should simply be treated as a file with no ACL. That's the least intrusive way, IMHO. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
