Re: cp failure to NetApp directory with CIFS security model
Clarence Donath [EMAIL PROTECTED] wrote: We are experiencing undesired behavior using 'cp' and its siblings involving a NetApp filer qtree with the CIFS security model. ... UNIX functions like chmod will fail, because changing of the permission bits is not allowed by the filer. ... What I assume is happening here is that 'cp' is trying to change the permissons of the file after it opens a new one for writing, and terminates when it cannot do so. This behavior occurs with coreutils versions 6.7 and 6.9, but not previous versions. Fixing this for you may be tricky, since it sounds like your file system cannot be POSIX-compliant. But first, have you tried a recent snapshot? http://meyering.net/cu/coreutils-6.9-ss.tar.gz http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig There have been changes in this area since 6.9. If that still fails, I suggest you run cp under strace or a debugger to see precisely which syscall is failing. Let us know. The changes that I think are giving you trouble were required to eliminate some race conditions ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp: cannot create regular file `lib/uniwidth/cjk.h-t': No such file or directory
A freshly checked out tree fails to bootstrap. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp failure to NetApp directory with CIFS security model
On Thu, 2007-11-01 at 08:36 +0100, Jim Meyering wrote:
Fixing this for you may be tricky, since it sounds like
your file system cannot be POSIX-compliant.
But first, have you tried a recent snapshot?
http://meyering.net/cu/coreutils-6.9-ss.tar.gz
http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig
There have been changes in this area since 6.9.
If that still fails, I suggest you run cp under strace or
a debugger to see precisely which syscall is failing. Let us know.
The changes that I think are giving you trouble
were required to eliminate some race conditions
Hello,
Thank you for investigating our issue.
This destination location is certainly not fully POSIX compliant. It's
a method NetApp has developed to allow UNIX user access to be controlled
by Windows ACLs.
Using the recent snapshot exhibits the same behavior.
Running strace using cp v6.9-354-68c33a produces the following...
[EMAIL PROTECTED]:/p/inet-strace /usr/local/bin/cp /root/cron /p/inet
[snip]
stat64(/p/inet, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64(/root/cron, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
stat64(/p/inet/cron, 0xbfb66bf4) = -1 ENOENT (No such file or
directory)
open(/root/cron, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
open(/p/inet/cron, O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1
EPERM (Operation not permitted)
write(2, /usr/local/bin/cp: , 19/usr/local/bin/cp: ) = 19
write(2, cannot create regular file `/p/i..., 41cannot create regular
file `/p/inet/cron') = 41
write(2, : Operation not permitted, 25: Operation not permitted) = 25
write(2, \n, 1
) = 1
close(3)= 0
close(0)= 0
close(1)= 0
close(2)= 0
exit_group(1) = ?
The resultant destination file is created, but left empty by 'cp'.
A second 'cp' will succeed since the file was created by the first 'cp'.
Running strace using cp v6.6 successfully copies the file, and produces
the following...
[EMAIL PROTECTED]:/p/inet-strace /usr/local/bin/cp /root/cron /p/inet
[snip]
stat64(/p/inet, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64(/root/cron, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
stat64(/p/inet/cron, 0xbf8e5954) = -1 ENOENT (No such file or
directory)
open(/root/cron, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
open(/p/inet/cron, O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 4
fstat64(4, {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
read(3, [EMAIL PROTECTED]..., 32768) = 486
write(4, [EMAIL PROTECTED]..., 486) = 486
close(4)= 0
close(3)= 0
close(1)= 0
close(2)= 0
exit_group(0) = ?
The new open() call causes cp to terminate. Is it the O_EXCL causing
this?
What concerns me is the following from the open() man page...
O_EXCL is broken on NFS file systems; programs which rely on
it for performing
locking tasks will contain a race condition.
Best regards,
Clarence Donath
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp: cannot create regular file `lib/uniwidth/cjk.h-t': No such file or directory
Andreas Schwab [EMAIL PROTECTED] wrote: A freshly checked out tree fails to bootstrap. Thanks for reporting it. I noticed not long after the gnulib change that provoked it, and Bob Proulx tracked it down to this seemingly-innocuous change: commit d5daff19f4a26e67e7c410cefa9ddc13e036162a Author: Bruno Haible [EMAIL PROTECTED] Date: Mon Oct 29 12:55:44 2007 +0100 If --lgpl is not specified, convert copyright headers to GPLv3+. Although a gnulib change provoked the failure, I think bootstrap needs to change now that cjk.h is generated via a different code path, but haven't looked into it yet. For now, you should be able to work around it by doing this first: mkdir lib/uniwidth ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp failure to NetApp directory with CIFS security model
Clarence Donath [EMAIL PROTECTED] wrote:
...
This destination location is certainly not fully POSIX compliant. It's
a method NetApp has developed to allow UNIX user access to be controlled
by Windows ACLs.
Using the recent snapshot exhibits the same behavior.
Running strace using cp v6.9-354-68c33a produces the following...
[EMAIL PROTECTED]:/p/inet-strace /usr/local/bin/cp /root/cron /p/inet
[snip]
stat64(/p/inet, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64(/root/cron, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
stat64(/p/inet/cron, 0xbfb66bf4) = -1 ENOENT (No such file or
directory)
open(/root/cron, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
open(/p/inet/cron, O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1
EPERM (Operation not permitted)
As you have guessed,
the problem seems to be the addition of the O_EXCL flag.
Earlier versions (including 6.6, below) of GNU cp didn't use O_EXCL,
and as such, were sometimes vulnerable to a symlink attack.
It looks like this is unrelated to permissions, in spite of the EPERM
failure. Rather, it may be that your server system mishandles the
O_CREAT|O_EXCL combination. That's supposed to make the open syscall
fail with EEXIST if the destination already exists.
Besides, if there's really an open _failure_ due to permissions,
it shouldn't it create the file at all.
...
The resultant destination file is created, but left empty by 'cp'.
A second 'cp' will succeed since the file was created by the first 'cp'.
Right, since it no longer tries to use the O_EXCL flag
when the destination file exists.
Running strace using cp v6.6 successfully copies the file, and produces
the following...
[EMAIL PROTECTED]:/p/inet-strace /usr/local/bin/cp /root/cron /p/inet
[snip]
stat64(/p/inet, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
stat64(/root/cron, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
stat64(/p/inet/cron, 0xbf8e5954) = -1 ENOENT (No such file or
directory)
open(/root/cron, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=486, ...}) = 0
open(/p/inet/cron, O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 4
fstat64(4, {st_mode=S_IFREG|0777, st_size=0, ...}) = 0
read(3, [EMAIL PROTECTED]..., 32768) = 486
write(4, [EMAIL PROTECTED]..., 486) = 486
close(4)= 0
close(3)= 0
close(1)= 0
close(2)= 0
exit_group(0) = ?
The new open() call causes cp to terminate. Is it the O_EXCL causing
this?
I suspect it's a bug in the file system code.
What concerns me is the following from the open() man page...
O_EXCL is broken on NFS file systems; programs which rely on
it for performing
locking tasks will contain a race condition.
Some people use the atomicity of O_CREAT|O_EXCL to implement
locks. That's just warning you that while it works fine on a
local file system, it will not work on an NFS-mounted file system.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp failure to NetApp directory with CIFS security model
Clarence Donath [EMAIL PROTECTED] wrote: open(/p/inet/cron, O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1 EPERM (Operation not permitted) ... The resultant destination file is created, but left empty by 'cp'. A second 'cp' will succeed since the file was created by the first 'cp'. A just-released security alert, https://rhn.redhat.com/errata/RHSA-2007-0939.html mentioned the following: * A flaw was found in the CIFS file system. This could cause the umask values of a process to not be honored on CIFS file systems where UNIX extensions are supported. (CVE-2007-3740, Important) cp relies heavily on how the process umask works. If your CIFS file system implementation is affected by the above-fixed bug, then that may explain the failure. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls: write error: Broken pipe
I have been using this alias: lt = 'ls -lt | head' for a long long time, on many systems. On Fedora 7 I get this from time to time: cd /usr/lib lt total 162508 drwxr-xr-x 10 rpm rpm 4096 2007-10-31 00:11 rpm/ drwxr-xr-x 13 root root 4096 2007-10-31 00:11 firefox-2.0.0.5/ drwxr-xr-x 3 root root 4096 2007-10-31 00:10 gthumb/ drwxr-xr-x 3 root root 4096 2007-10-31 00:10 scim-1.0/ drwxr-xr-x 4 root root 4096 2007-10-22 08:22 xemacs-21.5-b28/ drwxr-xr-x 4 root root 4096 2007-10-22 08:22 xemacs/ lrwxrwxrwx 1 root root 19 2007-10-22 08:22 libneXtaw.so.0 - libneXtaw.so.0.15.1* lrwxrwxrwx 1 root root 20 2007-10-22 08:22 libcompface.so.1 - libcompface.so.1.0.0* lrwxrwxrwx 1 root root 19 2007-10-22 08:22 libcanna16.so.1 - libcanna16.so.1.2.0* lrwxrwxrwx 1 root root 17 2007-10-22 08:22 libcanna.so.1 - libcanna.so.1.2.0* lrwxrwxrwx 1 root root 17 2007-10-22 08:22 libRKC16.so.1 - libRKC16.so.1.2.0* lrwxrwxrwx 1 root root 15 2007-10-22 08:22 libRKC.so.1 - libRKC.so.1.2.0* drwxr-xr-x 2 root root 4096 2007-10-19 10:16 tk8.4/ lrwxrwxrwx 1 root root 17 2007-10-19 10:16 tcl8.4 - /usr/share/tcl8.4/ lrwxrwxrwx 1 root root 27 2007-10-19 10:15 libsvn_swig_perl-1.so.0 - libsvn_swig_perl-1.so.0.0.0* drwxr-xr-x 2 root root 4096 2007-10-16 19:59 vte/ lrwxrwxrwx 1 root root 25 2007-10-11 06:54 libsvn_swig_py-1.so.0 - libsvn_swig_py-1.so.0.0.0* lrwxrwxrwx 1 root root 20 2007-10-11 06:54 libsvn_wc-1.so.0 - libsvn_wc-1.so.0.0.0* lrwxrwxrwx 1 root root 26 2007-10-11 06:54 libsvn_ra_local-1.so.0 - libsvn_ra_local-1.so.0.0.0* ls: write error: Broken pipe Is there any reason for this error to be printed? The strange thing is that I don't always get this error, I could run lt and not see the error, then run it again and see it. I am using: coreutils-6.9-3.fc7 Thanks --dan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] writes: ls: write error: Broken pipe Most likely you are trapping the PIPE signal. For example: 524-penguin $ ls -lR | head -1 .: 525-penguin $ trap '' PIPE 526-penguin $ ls -lR | head -1 .: ls: write error: Broken pipe 527-penguin $ This is on Debian stable, but Fedora should be similar. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -s Bug?
Marcus Nutzinger [EMAIL PROTECTED] writes: could anyone please explain in a few sentences, why the program behaves in this way? Because that's how the symlink system call behaves. It can't easily adjust the link to work in the way that you like, because it doesn't have enough information available in general. Consider the case, for instance, where you type ln -s a b/c/d and b/c is a symbolic link. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls: write error: Broken pipe
Dan Nicolaescu [EMAIL PROTECTED] wrote: I have been using this alias: lt = 'ls -lt | head' ... ls: write error: Broken pipe Is there any reason for this error to be printed? Hi Dan, You should see it only if you have changed the default signal handling to ignore SIGPIPE, and then only some of the time. When it's possible to see it, kernel buffering and the size of your environment also determine how much can be written before the signal is sent. Some programs (like git) prefer not to diagnose this type of write failure, but coreutils makes a point of never suppressing such diagnostics, because sometimes they're legitimate. This topic was beaten to death as a side effect of my patch to make git detect a bunch of previously-ignored write errors: http://thread.gmane.org/gmane.comp.version-control.git/48469/focus=48617 If you're bored, read on in that thread... it gets even more animated. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
git hints (cp: cannot create regular file `lib/uniwidth/cjk.h-t': No such file or directory)
Since use of git is still new to many people on the list I thought I reply with some general git hints for folks that might be following along. If you are already a git wizard then this won't be interesting to you. Jim Meyering wrote: Andreas Schwab [EMAIL PROTECTED] wrote: A freshly checked out tree fails to bootstrap. Thanks for reporting it. I noticed not long after the gnulib change that provoked it, and Bob Proulx tracked it down to this seemingly-innocuous change: commit d5daff19f4a26e67e7c410cefa9ddc13e036162a Author: Bruno Haible [EMAIL PROTECTED] Date: Mon Oct 29 12:55:44 2007 +0100 If --lgpl is not specified, convert copyright headers to GPLv3+. Individual commits can be viewed using the git-show command. Either the full commit signature or enough to be unique. I am just going to use the first few characters here. $ git show d5daff19 ...patch-like output... This will be automatically piped to your pager (in my case 'less') and so it is not necessary to explicitly pipe it to one. Although a gnulib change provoked the failure, I think bootstrap needs to change now that cjk.h is generated via a different code path, but haven't looked into it yet. For now, you should be able to work around it by doing this first: mkdir lib/uniwidth Or alternatively since there are only three commits in the upstream gnulib since this failure I have simply been building using the previous version of gnulib from version control. In my mind the whole purpose of version control is to create a safety net so that when a new change causes a problem that it can be easily dealt with by using previous known good versions. Since I am building with a separate gnulib in its own directory the version of gnulib can be selected separately from the version of coreutils. I am building coreutils using the './bootstrap --gnulib-src=../gnulib' option. $ cd ../gnulib $ git checkout -b gnulib-ss-working d5daff19^ By using '^' at the end this checks out the version above/before that version. This selects the last version that built successfully. This could easily have been 28d9a006 too since d5daff19^ means 28d9a006 in the gnulib history. (And of course the full long commit signature could have been used, as from a cut-n-paste, too. I just shortened it to make this message more readable.) The 'git-checkout -b gnulib-ss-working' creates a branch and names it gnulib-ss-working. This is necessary because git requires this to be a branch head where more versions _could_ be committed and the original master head already has commits after this point in the branch and so a new branch just to hold this must be created. When the gnulib problem is resolved this can be pulled back up to the latest HEAD of the branch. $ git checkout master After returning to the master branch's HEAD version the topic branch is no longer needed. It can be removed to clean it up. $ git branch -d gnulib-ss-working Using git to find these types of failures is made easier by the git-bisect command in git. This command handles the topic branches during the reduction process automatically. The idea is that if you have a point in time where things are one way (let's say working) and another point in time where things are another way (say not working) then you can perform a binary search through the list of versions between those two points and very quickly find the version where things change with a very few number of build attempts. I knew cd6b82c9 was a good version and planned to start the search there. git-rev-list cd6b82c9..master | wc -l 18 With 18 potential versions to test I wanted to reduce the number of potential build and test cycles and used git-bisect. Here is how a typical session goes. $ git checkout master $ git bisect start $ git bisect bad HEAD $ git bisect good cd6b82c9 Bisecting: 9 revisions left to test after this ...test... $ git bisect good Bisecting: 5 revisions left to test after this ...test... $ git bisect good Bisecting: 2 revisions left to test after this ...test... $ git bisect bad Bisecting: 1 revisions left to test after this ...test... $ git bisect good d5daff19f4a26e67e7c410cefa9ddc13e036162a is first bad commit ...use this version for a bit... Out of 18 versions the change was found in four test cycles. At any time during the testing you can invoke 'git-bisect visualize' to start up a 'gitk' visualizer to display graphically the versions that are in the suspected version list. This operates on a bisect branch. When done use 'git bisect reset' to clean up and return to the master branch on the branch head. $ git bisect reset # all done Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -s Bug?
Marcus Nutzinger [EMAIL PROTECTED] writes: But if I do the same, just with the -s option to create a symlink, the following happens: $ ls -l drwx-- 2 nuuz nuuz 4,0K 2007-11-01 15:13 dir -rw--- 1 nuuz nuuz0 2007-11-01 15:13 file $ ln -s file dir/ $ ls -l dir lrwxrwxrwx 1 nuuz nuuz 1 2007-11-01 15:14 file - file So file points to itself and not to ../file as I would expect it after creating the link. A symbolic link is just that: symbolic. The symlink target is merely a string that is interpreted only at the time the symlink is followed, other than that it has no inherent meaning at all. It does not even have to point to a valid file name, if you never try to follow the symlink you can put any kind of interpretation on the name of the target. For example, you can use a symlink as a kind of lock, encoding the owner pid into its target name. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -s Bug?
Paul Eggert wrote: Marcus Nutzinger [EMAIL PROTECTED] writes: could anyone please explain in a few sentences, why the program behaves in this way? Because that's how the symlink system call behaves. It can't easily adjust the link to work in the way that you like, because it doesn't have enough information available in general. Consider the case, for instance, where you type ln -s a b/c/d and b/c is a symbolic link. $ ln -s file dir/ $ ls -l dir lrwxrwxrwx 1 nuuz nuuz 1 2007-11-01 15:14 file - file So file points to itself and not to ../file as I would expect it after creating the link. Let me add that symbolic links are name translations. The value of the symbolic link is the string that you use to create the symbolic link. On some operating systems the size of the symlink is the number of characters in the link. On my system the above size is four characters to hold file. The value of the symlink is always the literal string (within validity limits) given on the command line. For the reasons Paul said the name can't be modified from what is specified on the command line because in general it can't know what is wanted. What you say is what you get. Nothing more and nothing less. It does not need to exist at the time that it is created. It may only be valid in some future context. Or it might never be valid as some applications use them only for the holding of a value and nothing more. $ ln -s 4321 barlink ...some time passes... $ echo some data 4321 Hard links (ln without the -s option) are immediate filesystem links of the inode of the two files. The inode reference count will increase. The directory will hold a pointer to the file. The file then exists on the filesystem by both canonical paths. This is not a name resolution. The file now resides in the new location. And in the old location too. The file must exist ahead of time. The file can only be linked on the same filesystem. Links across filesystems can't work. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -s Bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Let me add that symbolic links are name translations. The value of the symbolic link is the string that you use to create the symbolic link. I see! This means that the utility just doesn't want e.g. to resolve the absolute path of the symlink-target, because maybe it doesn't exist and maybe it will never exist and will only be used as lock (as Andreas wrote) or value holder. Now I also know why I didn't get it in the first place! I didn't realize that the first argument can also be non-existant. Now things are much clearer of course :) Thank you! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKhA9eEFjZ1Jaui4RAlm3AJ9IduMr9kuGsg2zjcWQOD9RmqoVcwCdHDPb k/kuFKKRy8BdvS0O4mVzwx8= =dc9Y -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp failure to NetApp directory with CIFS security model
Clarence Donath [EMAIL PROTECTED] writes: open(/p/inet/cron, O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1 EPERM (Operation not permitted) The resultant destination file is created, but left empty by 'cp'. Wow, open() creates the file but then returns -1? That's a serious bug in the OS or the filer. I don't offhand see an easy way to work around this bug in coreutils, without introducing some performance problems (or security holes) on non-buggy systems. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
new snapshot
Here are the usual tarballs and signatures. 3.5M http://meyering.net/cu/coreutils-6.9-ss.tar.lzma 8.5M http://meyering.net/cu/coreutils-6.9-ss.tar.gz aka 3.5M http://meyering.net/cu/coreutils-6.9-375-3e3f8.tar.lzma 8.5M http://meyering.net/cu/coreutils-6.9-375-3e3f8.tar.gz http://meyering.net/cu/coreutils-6.9-ss.tar.lzma.sig http://meyering.net/cu/coreutils-6.9-ss.tar.gz.sig Thanks to everyone who's given feedback. I really want to make a test release soon, but there are some minor problems: 1 bootstrap failure (minor) 2 make check fails on solaris due to use of /bin/sh vs. test-lib.sh and my new policy that using $(cmd) is now fair game in test scripts. Working around Solaris' ancient /bin/sh will require something like the re-exec-self-with-decent-shell trick used in configure. Just need to write it. This isn't a big deal: the work-around is to run this: find tests -type f|xargs perl -pi -e 's,^\#! ?/bin/sh$,#!/bin/ksh,' A patch to fix #2 properly would be most welcome, since I am not inclined to do it. FYI, I feel about this the same way I feel about uglifying C code to make it compile absolutely everywhere. We have to draw the line, and I want shell functions and $(cmd) (not `cmd`) notation in scripts. At worst, don't run the tests. If you're interested, autoconf's _AS_DETECT_REQUIRED macro looks promising. It might be able to generate code to be used in coreutils' tests/test-lib.sh that would re-exec a usable shell, when necessary. Here are the ChangeLog entries since the 354-68c33a snapshot: - 2007-11-01 Jim Meyering [EMAIL PROTECTED] * tests/misc/printf-surprise: Correct sed transform. Reported by Bob Proulx. Add example inspired by make dist running gzip and lzma in sequence. * doc/coreutils.texi (tee invocation): Show how to run tar just once, compressing the tee'd output streams in parallel. Say that the first process substitution example is contrived. * doc/coreutils.texi (tee invocation): ... and show how to do it properly. Pointed out by James Antill. Use mktemp, not mkdtemp, to create test directories. * tests/test-lib.sh: Use the mktemp binary we've just built, not the mkdtemp script. * tests/mkdtemp: Remove file. * tests/Makefile.am (EXTRA_DIST): Remove mkdtemp. Adjust a seq subtest not to depend on the vagaries of floating point. * tests/misc/seq (float-3): Use 10.94 as the endpoint, not 10.95, since 10.95 was precisely in the middle of the interval, and with a %.1f format could map to either 10.9 or 11.0. Reported by Mike Frysinger Make the new printf-surprise test more precise. * tests/test-lib.sh (require_ulimit_): New function. * tests/misc/printf-surprise: Use ulimit -v to trigger the fixed bug, and rather than checking printf's exit status (which would go wrong on FreeBSD 6.1, since their printf(3) function doesn't require lots of memory in this case) simply test whether it outputs the first 10 bytes. Accommodate FreeBSD 6.1 hard-link-to-symlink differences. * tests/cp/same-file: Detect when linking to a symlink links to the target of the symlink (FreeBSD 6.1 does this, Linux does not), and skip the few tests that would otherwise fail. Redirect output of final comparison to stderr, since all stdout is already redirected. 2007-10-31 Jim Meyering [EMAIL PROTECTED] Fix a make distcheck failure. * Makefile.maint (my-distcheck): Don't stub-out dirname, since build-aux/check.mk now uses it. * bootstrap.conf (gnulib_modules): Add xprintf-posix. 2007-10-30 Jim Meyering [EMAIL PROTECTED] Avoid seq floating-point test failure on FreeBSD 6.1. * tests/misc/seq (float-4): Also accept -0.0. 2007-10-29 Jim Meyering [EMAIL PROTECTED] Change a make dist diagnostic. * GNUmakefile: Don't imply that $(_curr-ver) is the new version string. 2007-10-29 Bob Proulx [EMAIL PROTECTED] Improve color terminal escape usage. * build-aux/check.mk (am__tty_colors): Use 'tput' to deduce terminal color capabilities. 2007-10-29 Jim Meyering [EMAIL PROTECTED] Don't try to colorize a dumb terminal. * build-aux/check.mk (am__tty_colors): Skip colors if $TERM is dumb. Thanks to Bob Proulx. Remove gnulib's printf-posix module, for now. * bootstrap.conf (gnulib_modules): It caused too many test failures. Remove spurious semicolon after else. * build-aux/check.mk (am__tty_colors): Fix syntax error. If $TERM is empty, don't use colors. This helps the buildbot, since it produces its result in an environment with a tty, but we don't want color codes in that case. *
Re: cp failure to NetApp directory with CIFS security model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 11/1/2007 2:27 PM: Clarence Donath [EMAIL PROTECTED] writes: open(/p/inet/cron, O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1 EPERM (Operation not permitted) The resultant destination file is created, but left empty by 'cp'. Wow, open() creates the file but then returns -1? That's a serious bug in the OS or the filer. FWIW, CVS cygwin had a similar bug for about a one month window a while ago: http://cygwin.com/ml/cygwin/2007-09/msg00407.html I found it very annoying when using cygwin snapshots where mv would fail but cp succeed, all because open was creating the file while returning -1. Fortunately, current cygwin snapshots no longer have this bug. I don't offhand see an easy way to work around this bug in coreutils, without introducing some performance problems (or security holes) on non-buggy systems. Agreed. I would push back on the CIFS people to fix their bug. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKnPd84KuGfSFAYARAsNnAJ9IzwgKnjvn1KR21KInWcjCDbDu4QCgqL2g drUS4KGXP6PnwXPUERanpw4= =wbfu -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
