please test: coreutils-5.90-1

please test: coreutils-5.90-1

[Eric Blake]

I've uploaded a test version of coreutils, 5.90-1.  This is a new, unstable 
upstream release, with a number of changes from 5.3.0.  In particular, quite 
a few changes have been made upstream in regards to text vs. binary mode, so 
some feedback on this list would be appreciated before I promote the version 
to current (5.3.0-9 will remain current at least as long as cygwin-1.5.18-1 
stays current).  A full list from the NEWS file appears below.  I think 
5.90-1 will work with 1.5.18, but my testing to date has only been on cygwin 
snapshots.  As coreutils provides quite a bit of programs in daily use, I 
would recommend that you not upgrade to the test version UNLESS you are 
willing to cope with and report regressions.

-- 
Someday, I might put a cute statement here.

Eric Blake             ebb9@byu.net
volunteer cygwin coreutils maintainer

* Major changes in release 5.90 (2005-09-29) [unstable]

** Bring back support for `head -NUM', `tail -NUM', etc. even when
   conforming to POSIX 1003.1-2001.  The following changes apply only
   when conforming to POSIX 1003.1-2001; there is no effect when
   conforming to older POSIX versions.

   The following usages now behave just as when conforming to older POSIX:

     date -I
     expand -TAB1[,TAB2,...]
     fold -WIDTH
     head -NUM
     join -j FIELD
     join -j1 FIELD
     join -j2 FIELD
     join -o FIELD_NAME1 FIELD_NAME2...
     nice -NUM
     od -w
     pr -S
     split -NUM
     tail -[NUM][bcl][f] [FILE]

   The following usages no longer work, due to the above changes:

     date -I TIMESPEC  (use `date -ITIMESPEC' instead)
     od -w WIDTH       (use `od -wWIDTH' instead)
     pr -S STRING      (use `pr -SSTRING' instead)

   A few usages still have behavior that depends on which POSIX standard is
   being conformed to, and portable applications should beware these
   problematic usages.  These include:

     Problematic       Standard-conforming replacement, depending on
        usage            whether you prefer the behavior of:
                       POSIX 1003.2-1992    POSIX 1003.1-2001
     sort +4           sort -k 5            sort ./+4
     tail +4           tail -n +4           tail ./+4
     tail - main.c     tail main.c          tail -- - main.c
     tail -c 4         tail -c 10 ./4       tail -c4
     touch 12312359 f  touch -t 12312359 f  touch ./12312359 f
     uniq +4           uniq -s 4            uniq ./+4

   These changes are in response to decisions taken in the January 2005
   Austin Group standardization meeting.  For more details, please see
   "Utility Syntax Guidelines" in the Minutes of the January 2005
   Meeting <http://www.opengroup.org/austin/docs/austin_239.html>.

** Binary input and output are now implemented more consistently.
   These changes affect only platforms like MS-DOS that distinguish
   between binary and text files.

   The following programs now always use text input/output:

     expand unexpand

   The following programs now always use binary input/output to copy data:

     cp install mv shred

   The following programs now always use binary input/output to copy
   data, except for stdin and stdout when it is a terminal.

     head tac tail tee tr
     (cat behaves similarly, unless one of the options -bensAE is used.)

   cat's --binary or -B option has been removed.  It existed only on
   MS-DOS-like platforms, and didn't work as documented there.

   md5sum and sha1sum now obey the -b or --binary option, even if
   standard input is a terminal, and they no longer report files to be
   binary if they actually read them in text mode.

** Changes for better conformance to POSIX

   cp, ln, mv, rm changes:

     Leading white space is now significant in responses to yes-or-no questions.
     For example, if "rm" asks "remove regular file `foo'?" and you respond
     with " y" (i.e., space before "y"), it counts as "no".

   dd changes:

     On a QUIT or PIPE signal, dd now exits without printing statistics.

     On hosts lacking the INFO signal, dd no longer treats the USR1
     signal as if it were INFO when POSIXLY_CORRECT is set.

     If the file F is non-seekable and contains fewer than N blocks,
     then before copying "dd seek=N of=F" now extends F with zeroed
     blocks until F contains N blocks.

   fold changes:

     When POSIXLY_CORRECT is set, "fold file -3" is now equivalent to
     "fold file ./-3", not the obviously-erroneous "fold file ./-w3".

   ls changes:

     -p now marks only directories; it is equivalent to the new option
     --indicator-style=slash.  Use --file-type or
     --indicator-style=file-type to get -p's old behavior.

   nice changes:

     Documentation and diagnostics now refer to "nicenesses" (commonly
     in the range -20...19) rather than "nice values" (commonly 0...39).

   nohup changes:

     nohup now ignores the umask when creating nohup.out.

     nohup now closes stderr if it is a terminal and stdout is closed.

     nohup now exits with status 127 (not 1) when given an invalid option.

   pathchk changes:

     It now rejects the empty name in the normal case.  That is,
     "pathchk -p ''" now fails, and "pathchk ''" fails unless the
     current host (contra POSIX) allows empty file names.

     The new -P option checks whether a file name component has leading "-",
     as suggested in interpretation "Austin-039:XCU:pathchk:pathchk -p"
     <http://www.opengroup.org/austin/interps/doc.tpl?gdid=6232>.
     It also rejects the empty name even if the current host accepts it; see
     <http://www.opengroup.org/austin/interps/doc.tpl?gdid=6233>.

     The --portability option is now equivalent to -p -P.

** Bug fixes

   chmod, mkdir, mkfifo, and mknod formerly mishandled rarely-used symbolic
   permissions like =xX and =u, and did not properly diagnose some invalid
   strings like g+gr, ug,+x, and +1.  These bugs have been fixed.

   csplit could produce corrupt output, given input lines longer than 8KB

   dd now computes statistics using a realtime clock (if available)
   rather than the time-of-day clock, to avoid glitches if the
   time-of-day is changed while dd is running.  Also, it avoids
   using unsafe code in signal handlers; this fixes some core dumps.

   expr and test now correctly compare integers of unlimited magnitude.

   expr now detects integer overflow when converting strings to integers,
   rather than silently wrapping around.

   ls now refuses to generate time stamps containing more than 1000 bytes, to
   foil potential denial-of-service attacks on hosts with very large stacks.

   "mkdir -m =+x dir" no longer ignores the umask when evaluating "+x",
   and similarly for mkfifo and mknod.

   "mkdir -p /tmp/a/b dir" no longer attempts to create the `.'-relative
   directory, dir (in /tmp/a), when, after creating /tmp/a/b, it is unable
   to return to its initial working directory.  Similarly for "install -D
   file /tmp/a/b/file".

   "pr -D FORMAT" now accepts the same formats that "date +FORMAT" does.

   stat now exits nonzero if a file operand does not exist

** Improved robustness

   Date no longer needs to allocate virtual memory to do its job,
   so it can no longer fail due to an out-of-memory condition,
   no matter how large the result.

** Improved portability

   hostid now prints exactly 8 hexadecimal digits, possibly with leading zeros,
   and without any spurious leading "fff..." on 64-bit hosts.

   nice now works on Darwin 7.7.0 in spite of its invalid definition of NZERO.

   `rm -r' can remove all entries in a directory even when it is on a
   file system for which readdir is buggy and that was not checked by
   coreutils' old configure-time run-test.

   sleep no longer fails when resumed after being suspended on linux-2.6.8.1,
   in spite of that kernel's buggy nanosleep implementation.

** New features

   chmod -w now complains if its behavior differs from what chmod a-w
   would do, and similarly for chmod -r, chmod -x, etc.

   cp and mv: the --reply=X option is deprecated

   date accepts the new option --rfc-3339=TIMESPEC.  The old --iso-8602 (-I)
   option is deprecated; it still works, but new applications should avoid it.
   date, du, ls, and pr's time formats now support new %:z, %::z, %:::z
   specifiers for numeric time zone offsets like -07:00, -07:00:00, and -07.

   dd has new iflag= and oflag= flags "binary" and "text", which have an
   effect only on nonstandard platforms that distinguish text from binary I/O.

   du accepts new options: --time[=TYPE] and --time-style=STYLE

   join now supports a NUL field separator, e.g., "join -t '\0'".
   join now detects and reports incompatible options, e.g., "join -t x -t y",

   ls no longer outputs an extra space between the mode and the link count
   when none of the listed files has an ACL.

   md5sum --check now accepts multiple input files, and similarly for sha1sum.

   If stdin is a terminal, nohup now redirects it from /dev/null to
   prevent the command from tying up an OpenSSH session after you logout.

   "rm -FOO" now suggests "rm ./-FOO" if the file "-FOO" exists and
   "-FOO" is not a valid option.

   stat -f -c %S outputs the fundamental block size (used for block counts).
   stat -f's default output format has been changed to output this size as well.
   stat -f recognizes file systems of type XFS and JFS

   "touch -" now touches standard output, not a file named "-".

   uname -a no longer generates the -p and -i outputs if they are unknown.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-1

[David Rothenberger]

On 10/1/2005 8:34 PM, Eric Blake wrote:
> I've uploaded a test version of coreutils, 5.90-1.  This is a new, 
> unstable upstream release, with a number of changes from 5.3.0.  In 
> particular, quite a few changes have been made upstream in regards to 
> text vs. binary mode, so some feedback on this list would be appreciated 
> before I promote the version to current (5.3.0-9 will remain current at 
> least as long as cygwin-1.5.18-1 stays current).  A full list from the 
> NEWS file appears below.  I think 5.90-1 will work with 1.5.18, but my 
> testing to date has only been on cygwin snapshots.  As coreutils 
> provides quite a bit of programs in daily use, I would recommend that 
> you not upgrade to the test version UNLESS you are willing to cope with 
> and report regressions.
> 

With 5.90-1:

% mkdir -p /tmp/foo
mkdir: `/tmp/foo' exists but is not a directory

There is no /tmp/foo. With 5.3.0-9, this works fine.

-- 
David Rothenberger                spammer? -> spam@daveroth.dyndns.org
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734

"The human brain is like an enormous fish -- it is flat and slimy and
has gills through which it can see."
		-- Monty Python


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-1

[Corinna Vinschen]

On Oct  1 21:34, Eric Blake wrote:
> I've uploaded a test version of coreutils, 5.90-1.  [...]
>   cat's --binary or -B option has been removed.  It existed only on
>   MS-DOS-like platforms, and didn't work as documented there.

How is that supposed to work in future?  Cat is a texttool so it
seems not to be safe to let the --binary option go.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-1

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to David Rothenberger on 10/3/2005 4:31 PM:
> With 5.90-1:
> 
> % mkdir -p /tmp/foo
> mkdir: `/tmp/foo' exists but is not a directory
> 
> There is no /tmp/foo. With 5.3.0-9, this works fine.

My bad.  The code in lib/mkdir-p.c changed from 5.3.0, but my forward
porting of my cygwin-specific patch in 5.3.0 did not take that into
account.  It will be fixed in 5.90-2, although I might wait a few more
days in case there is anything else to fix as well.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQnMw84KuGfSFAYARAo86AJ9yEjnf36e4EUNT0UogyvZ000NQNwCfZuwY
WZwcW3r/iHmENmc/3ZGZj6w=
=Fr1k
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-1

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 10/4/2005 2:11 AM:
> On Oct  1 21:34, Eric Blake wrote:
> 
>>I've uploaded a test version of coreutils, 5.90-1.  [...]
>>  cat's --binary or -B option has been removed.  It existed only on
>>  MS-DOS-like platforms, and didn't work as documented there.
> 
> 
> How is that supposed to work in future?  Cat is a texttool so it
> seems not to be safe to let the --binary option go.

In the upstream sources, --binary was unquestionably broken, among a maze
of #ifdefs and attempted support for DJGPP.  There was a cygwin-specific
patch to try to rectify it applied in 5.2.1 which I forward ported to
5.3.0, but I have not analyzed it closely enough to see if it still made
sense in every situation.  But on a quick inspection, it looks to me like
the only time --binary made any difference was with the -n, -s, or -E options.

In 5.90, the upstream sources removed DJGPP support, and have no ifdefs,
so it is easier to follow.  Also, it always uses binary mode unless -n,
- -s, or -E is specified.  The argument against binary in those three modes
is that a line containing just CR-LF is no longer an empty line when read
in binary mode, combined with the fact that those three options munge the
output according to whether the line is empty or not.  Furthermore,
neither -n, -s, nor -E are required by POSIX, so they have no requirements
that they have to operate in a binary mode.  Therefore, having a --binary
option makes no sense, at least in the upstream maintainer's viewpoint.

If anyone really ever did use `cat -s --binary' to purposefully make -s
read input in binary, then speak up now.  It would only make a difference
if you cat a file that resides on a text mount.  I doubt that it was
well-used, but if so, then the argument can still be made that upstream
should not have removed the option; and I can still see about maintaining
a cygwin-specific patch that restores a rudimentary --binary option even
if upstream stays by their decision to no longer maintain a --binary option.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQnr284KuGfSFAYARAmJGAKCJ61WQYZt/Af+h32XpDWrtYBQg9QCfUhQU
lPTzcy+Q06TvNWWR1Z/CdRU=
=9j5l
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

please test: coreutils-5.90-2

[Eric Blake]

Eric Blake <ebb9 <at> byu.net> writes:

> 
> I've uploaded a test version of coreutils, 5.90-1.  This is a new, unstable 
> upstream release, with a number of changes from 5.3.0.  In particular, quite 
> a few changes have been made upstream in regards to text vs. binary mode, so 
> some feedback on this list would be appreciated before I promote the version 
> to current (5.3.0-9 will remain current at least as long as cygwin-1.5.18-1 
> stays current).  A full list from the NEWS file appears below.  I think 
> 5.90-1 will work with 1.5.18, but my testing to date has only been on cygwin 
> snapshots.  As coreutils provides quite a bit of programs in daily use, I 
> would recommend that you not upgrade to the test version UNLESS you are 
> willing to cope with and report regressions.
> 

My bug in 'mkdir -p' in 5.90-1 proved immensely annoying, crippling such things
as attempting to build the cygwin dll from CVS.  So I have uploaded 5.90-2.  See
the earlier announcement,
http://sources.redhat.com/ml/cygwin/2005-10/msg00020.html, for the NEWS of
changes between 5.3.0 and 5.90.

Again, I am posting this as a test release.  This time, the release was compiled
against a cygwin snapshot, and WILL NOT WORK with cygwin 1.5.18 (a number of the
utilities depend on getline and getdelim, which were not present in 1.5.18).  If
you are going to test coreutils-5.90-2, you must first download a recent
snapshot of cygwin1.dll (20051003 has been working fine for me).  If you don't
know how to do that, then you are safer off sticking with the default
coreutils-5.3.0-9.  I would appreciate any feedback, so that when cygwin-1.5.19
is released, I can make this the current version of coreutils.

--
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-2

[David Rothenberger]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On 10/8/2005 7:29 PM, Eric Blake wrote:
> Eric Blake <ebb9 <at> byu.net> writes:
> My bug in 'mkdir -p' in 5.90-1 proved immensely annoying, crippling such things
> as attempting to build the cygwin dll from CVS.  So I have uploaded 5.90-2.

I'm having another problem with 'mkdir -p' in 5.90-2.

I have a script that attempts to do "mkdir -p c:/dir1/dir2/dir3". This 
started failing with a permission denied error for c:/.

I eventually discovered that it also fails using unix paths if the 
absolute path provided to mkdir starts at the root of a Windows drive. 
Here's a little example:

% mkdir /tmp/foo
% mount e:\\ /tmp/foo
% mkdir -p /tmp/foo/bar
mkdir: cannot create directory `/tmp/foo': Permission denied
% mkdir /tmp/foo/bar

(e: is a real drive on my system.)

I have my cygdrive prefix set to '/'. Commands like "mkdir -p /c/foo" 
also failed even though "mkdir /c/foo" succeeded.

This is with a home-built CVS DLL corresponding to the 20051003 snapshot.

-- 
David Rothenberger                spammer? -> spam@daveroth.dyndns.org
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734

"... all the good computer designs are bootlegged; the formally planned
products, if they are built at all, are dogs!"
		-- David E. Lundstrom, "A Few Good Men From Univac",
		   MIT Press, 1987

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: please test: coreutils-5.90-2

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to David Rothenberger on 10/11/2005 4:13 PM:
> I'm having another problem with 'mkdir -p' in 5.90-2.
> 
> I have a script that attempts to do "mkdir -p c:/dir1/dir2/dir3". This
> started failing with a permission denied error for c:/.

Hmm.  It worked perfectly for me on Win98, on both local and remote
drives.  But on WinXP, I got different behavior for the remote FAT than I
did for the local NTFS:

$ df -T c: j:
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
c:    system,fixed    29286460  20471796   8814664  70% /cygdrive/c
j:   system,remote     6260992   4508800   1752192  73% /cygdrive/j
$ mkdir -p j:/dir
$ mkdir -p c:/dir
mkdir: cannot create directory `c:': Permission denied

I am suspecting a cygwin bug here.  mkdir("c:") should fail with EEXIST,
not EACCES.  5.90 exposes this bug, where 5.3.0 did not, because the
algorithm for mkdir -p was changed to attempt mkdir() first instead of stat().

Continuing the example, I also find it odd that from WinXP, I get EBADRQC
instead of the more familiar ENOENT when removing a nonexistant directory
on a remote FAT drive:

$ rmdir j:/dir
$ rmdir j:/dir
rmdir: j:/dir: Invalid request code
$ rmdir c:/dir
rmdir c:/dir: No such file or directory

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
volunteer cygwin coreutils maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDTIEA84KuGfSFAYARAo3fAKDPQhWwrDCVk8O19Bro3l9x9JcIHACfeBdH
mtVpDwmo5aNXCOeRqgKxH+0=
=UCoL
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-2

[Corinna Vinschen]

On Oct 11 21:20, Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to David Rothenberger on 10/11/2005 4:13 PM:
> > I'm having another problem with 'mkdir -p' in 5.90-2.
> > 
> > I have a script that attempts to do "mkdir -p c:/dir1/dir2/dir3". This
> > started failing with a permission denied error for c:/.
> 
> Hmm.  It worked perfectly for me on Win98, on both local and remote
> drives.  But on WinXP, I got different behavior for the remote FAT than I
> did for the local NTFS:
> 
> $ df -T c: j:
> Filesystem    Type   1K-blocks      Used Available Use% Mounted on
> c:    system,fixed    29286460  20471796   8814664  70% /cygdrive/c
> j:   system,remote     6260992   4508800   1752192  73% /cygdrive/j
> $ mkdir -p j:/dir
> $ mkdir -p c:/dir
> mkdir: cannot create directory `c:': Permission denied
> 
> I am suspecting a cygwin bug here.  mkdir("c:") should fail with EEXIST,
> not EACCES.  5.90 exposes this bug, where 5.3.0 did not, because the
> algorithm for mkdir -p was changed to attempt mkdir() first instead of stat().
> 
> Continuing the example, I also find it odd that from WinXP, I get EBADRQC
> instead of the more familiar ENOENT when removing a nonexistant directory
> on a remote FAT drive:

The error codes returned from a remote FAT filesystem on a 9x based
host are for some reason entirely different than the error codes you'd
expect from other experiences.

In both of the above cases, it would be helpful to run mkdir under
strace and search for the Win32 error number, usually in a line with
`geterrno_from_win_error' in it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: please test: coreutils-5.90-2

[Corinna Vinschen]

On Oct 12 09:47, Corinna Vinschen wrote:
> On Oct 11 21:20, Eric Blake wrote:
> > $ df -T c: j:
> > Filesystem    Type   1K-blocks      Used Available Use% Mounted on
> > c:    system,fixed    29286460  20471796   8814664  70% /cygdrive/c
> > j:   system,remote     6260992   4508800   1752192  73% /cygdrive/j
> > $ mkdir -p j:/dir
> > $ mkdir -p c:/dir
> > mkdir: cannot create directory `c:': Permission denied
> > 
> > I am suspecting a cygwin bug here.  mkdir("c:") should fail with EEXIST,
> > not EACCES.  5.90 exposes this bug, where 5.3.0 did not, because the
> > algorithm for mkdir -p was changed to attempt mkdir() first instead of stat().

This is a problem in the new mkdir.  When trying to call CreateDirectory
on a local root directory, the error returned by Windows is
ERROR_ACCESS_DENIED, not ERROR_ALREADY_EXISTS.  Consequentially the error
is converted to EACCES, not EEXIST.  This is an error condition which mkdir
should handle gracefully.  I have serious problems to change this in
Cygwin since we can't find out why ERROR_ACCESS_DENIED has been returned
without jumping through loops.

> > Continuing the example, I also find it odd that from WinXP, I get EBADRQC
> > instead of the more familiar ENOENT when removing a nonexistant directory
> > on a remote FAT drive:

Trying to remove a non-existant directory on a 9x share apparently
returns ERROR_INVALID_FUNCTION instead of ERROR_FILE_NOT_FOUND.  I've
kludged this to be converted accordingly.  Nothing new here.  We're
used to convert 9x error messages into useful error messages...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

mkdir(2) bug [Was: please test: coreutils-5.90-2]

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 10/12/2005 1:47 AM:
>>I am suspecting a cygwin bug here.  mkdir("c:") should fail with EEXIST,
>>not EACCES.  5.90 exposes this bug, where 5.3.0 did not, because the
>>algorithm for mkdir -p was changed to attempt mkdir() first instead of stat().

With this simple program:

#include <stdio.h>
#include <sys/stat.h>
#include <errno.h>
#include <string.h>

int
main (int argc, char* argv[])
{
  int i;
  if (argc == 1)
    argc = 2; /* pass NULL */
  for (i = 1; i < argc; i++)
    {
      errno = 0;
      mkdir (argv[i], S_IRWXU|S_IRWXG|S_IRWXO);
      printf("%s: %d %s\n", argv[i] ? argv[i] : "NULL", errno,
             strerror(errno));
    }
  return 0;
}

I see the following bugs:

$ ./foo //   # should fail with EEXIST, not EROFS; no Windows call made
//: 30 Read-only file system
$ strace ./foo // | grep -B3 mkdir
   65   18986 [main] foo 3788 build_fh_pc: fh 0x6115AE1C
   34   19020 [main] foo 3788 path_conv::check: \\ is on a read-only
filesystem
   29   19049 [main] foo 3788 __set_errno: fhandler_base*
build_fh_name(const char*, void*, unsigned int, suffix_info*):347 val 30
   29   19078 [main] foo 3788 mkdir: got 30 error from build_fh_name
   27   19105 [main] foo 3788 __set_errno: int mkdir(const char*,
mode_t):274 val 30
   64   19169 [main] foo 3788 mkdir: -1 = mkdir (//, 511)

$ ./foo c:   # should fail with EEXIST, not EACCES
c:: 13 Permission denied
$ strace ./foo c: | grep -B3 mkdir
   69  141826 [main] foo 1368 seterrno_from_win_error:
/netrel/src/cygwin-snapshot-20051003-1/winsup/cygwin/fhandler_disk_file.cc:1225
windows error 5
   43  141869 [main] foo 1368 geterrno_from_win_error: windows error 5 ==
errno 13
   28  141897 [main] foo 1368 __set_errno: void
seterrno_from_win_error(const char*, int, DWORD):310 val 13
   54  141951 [main] foo 1368 mkdir: -1 = mkdir (c:, 511)

$ ./foo /proc    # should fail with EEXIST, not EROFS
/proc: 30 Read-only file system

$ mkdir a
$ ./foo a     # gives correct failure
a: 17 File exists
$ ./foo a/.   # should fail with EEXIST, not ENOENT
a/.: 2 No such file or directory
$ strace ./foo a/. | grep -B3 mkdir
   80   17961 [main] foo 760 dll_crt0_1: user_data->main 0x401050
   33   17994 [main] foo 760 __set_errno: void dll_crt0_1(char*):894 val 0
   29   18023 [main] foo 760 wait_for_sigthread: wait_sig_inited 0x71C
  117   18140 [main] foo 760 __set_errno: int mkdir(const char*,
mode_t):264 val 2


But this worked:
$ ./foo j:    # j: is a remote FAT drive, gives correct failure
j:: 17 File exists
$ strace ./foo j: | grep -B3 mkdir
  256   18952 [main] foo 3044 seterrno_from_win_error:
/netrel/src/cygwin-snapshot-20051003-1/winsup/cygwin/fhandler_disk_file.cc:1225
windows error 183
   76   19028 [main] foo 3044 geterrno_from_win_error: windows error 183
== errno 17
   30   19058 [main] foo 3044 __set_errno: void
seterrno_from_win_error(const char*, int, DWORD):310 val 17
  301   19359 [main] foo 3044 mkdir: -1 = mkdir (j:, 511)


>>
>>Continuing the example, I also find it odd that from WinXP, I get EBADRQC
>>instead of the more familiar ENOENT when removing a nonexistant directory
>>on a remote FAT drive:
> 
> 
> The error codes returned from a remote FAT filesystem on a 9x based
> host are for some reason entirely different than the error codes you'd
> expect from other experiences.
> 
> In both of the above cases, it would be helpful to run mkdir under
> strace and search for the Win32 error number, usually in a line with
> `geterrno_from_win_error' in it.

Modifying the above program in the obvious way (#include <unistd.h>, then
call rmdir() instead of mkdir()), shows the following bug (but in general,
most everything I threw at rmdir() worked):

$ ./foo j:/dir    # j:/dir doesn't exist, should fail with ENOENT
j:/dir: 54 Invalid request code
$ strace ./foo j:/dir 2>&1 |grep -B3 rmdir
 1071   28665 [main] foo 5812 seterrno_from_win_error:
/netrel/src/cygwin-snapshot-20051003-1/winsup/cygwin/fhandler_disk_file.cc:1290
windows error 1
  110   28775 [main] foo 5812 geterrno_from_win_error: windows error 1 ==
errno 54
   42   28817 [main] foo 5812 __set_errno: void
seterrno_from_win_error(const char*, int, DWORD):310 val 54
   33   28850 [main] foo 5812 rmdir: -1 = rmdir (j:/dir)

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDTQiA84KuGfSFAYARAgwNAJ9ft0m9h5IqTtwIFnuDNQpsrQdLGQCfcYy5
EeGxcdmOfdl1uRA3wGvWPIs=
=WYdm
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: mkdir(2) bug [Was: please test: coreutils-5.90-2]

[Corinna Vinschen]

On Oct 12 06:58, Eric Blake wrote:
> I see the following bugs:
> 
> $ ./foo //   # should fail with EEXIST, not EROFS; no Windows call made
> //: 30 Read-only file system
> $ strace ./foo // | grep -B3 mkdir
>    65   18986 [main] foo 3788 build_fh_pc: fh 0x6115AE1C
>    34   19020 [main] foo 3788 path_conv::check: \\ is on a read-only
> filesystem
>    29   19049 [main] foo 3788 __set_errno: fhandler_base*
> build_fh_name(const char*, void*, unsigned int, suffix_info*):347 val 30
>    29   19078 [main] foo 3788 mkdir: got 30 error from build_fh_name
>    27   19105 [main] foo 3788 __set_errno: int mkdir(const char*,
> mode_t):274 val 30
>    64   19169 [main] foo 3788 mkdir: -1 = mkdir (//, 511)

We had this already.  There's no such thing as a "correct" order of error
messages.  EROFS is as correct as EEXIST.  If coreutils don't allow
different correct error messages to be returned, than coreutils is just
not foolproof enough.  If this isn't a problem with coreutils, than the
better.

> $ ./foo c:   # should fail with EEXIST, not EACCES
> c:: 13 Permission denied
> $ strace ./foo c: | grep -B3 mkdir
>    69  141826 [main] foo 1368 seterrno_from_win_error:
> /netrel/src/cygwin-snapshot-20051003-1/winsup/cygwin/fhandler_disk_file.cc:1225
> windows error 5
>    43  141869 [main] foo 1368 geterrno_from_win_error: windows error 5 ==
> errno 13
>    28  141897 [main] foo 1368 __set_errno: void
> seterrno_from_win_error(const char*, int, DWORD):310 val 13
>    54  141951 [main] foo 1368 mkdir: -1 = mkdir (c:, 511)

See my previous mail on this subject.

> $ ./foo /proc    # should fail with EEXIST, not EROFS
> /proc: 30 Read-only file system

See above.

> $ ./foo a/.   # should fail with EEXIST, not ENOENT
> a/.: 2 No such file or directory

I get ENOENT on Linux.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: mkdir(2) bug [Was: please test: coreutils-5.90-2]

[Eric Blake]

> > On Oct 12 06:58, Eric Blake wrote:
> > > I see the following bugs:
> > > 
> > > $ ./foo //   # should fail with EEXIST, not EROFS; no Windows call made
> > 
> > We had this already.  There's no such thing as a "correct" order of error
> > messages.  EROFS is as correct as EEXIST.  If coreutils don't allow
> > different correct error messages to be returned, than coreutils is just
> > not foolproof enough.  If this isn't a problem with coreutils, than the
> > better.
> 
> OK, for //, you win - POSIX requires EROFS ONLY if the PARENT directory
> is read only, but the parent of // is //.  Fortunately, mkdir -p never
> tries to do mkdir("//").

Followup - this behavior of returning EROFS breaks
mkdir -p //server/share in 5.90.  Returning EEXIST really would be more
appropriate, but I will file an upstream bug to see whether they agree
that EROFS should be treated as a reason to call stat() to see if it
should have been EEXIST, rather than blindly failing on EROFS (this
affects non-cygwin systems, too, since you can mount writable
directories inside a read-only system).

--
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: mkdir(2) bug [Was: please test: coreutils-5.90-2]

[Eric Blake]

> On Oct 12 06:58, Eric Blake wrote:
> > I see the following bugs:
> > 
> > $ ./foo //   # should fail with EEXIST, not EROFS; no Windows call made
> 
> We had this already.  There's no such thing as a "correct" order of error
> messages.  EROFS is as correct as EEXIST.  If coreutils don't allow
> different correct error messages to be returned, than coreutils is just
> not foolproof enough.  If this isn't a problem with coreutils, than the
> better.

OK, for //, you win - POSIX requires EROFS ONLY if the PARENT directory
is read only, but the parent of // is //.  Fortunately, mkdir -p never
tries to do mkdir("//").

> 
> > $ ./foo /proc    # should fail with EEXIST, not EROFS
> > /proc: 30 Read-only file system
> 
> See above.

But for /proc, you are wrong - the parent directory / is not read
only, so POSIX only allows mkdir("/proc") to fail with EEXIST
and not EROFS.

> 
> > $ ./foo c:   # should fail with EEXIST, not EACCES
> 
> See my previous mail on this subject.

Isn't it just a matter of checking if the original filename was
a drive letter (a simple string comparison, no windows calls
at all), and only on the error path of EACCESS (so it won't
penalize the normal successful path)?

> 
> > $ ./foo a/.   # should fail with EEXIST, not ENOENT
> > a/.: 2 No such file or directory
> 
> I get ENOENT on Linux.

When? Before or after a exists?  It makes a difference (this
trace is on Solaris 8):

% ls a
ls: a: No such file or directory
% ./foo a/.
a/.: 2 No such file or directory
% ./foo a/
a/: 0 Error 0
% ./foo a/.
a/.: 17 File exists

Cygwin is blindly returning ENOENT, without first checking
whether a/ exists.  ENOENT is only permitted if a doesn't
exist; otherwise it must be EEXIST.

--
Eric Blake



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/