GNU bug report logs -
#6053
cp, ls, and mv bug: unknown error (252)
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6053 in the body.
You can then email your comments to 6053 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 27 Apr 2010 14:07:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Callahan, Patrick M." <pat.callahan <at> gd-ais.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Tue, 27 Apr 2010 14:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When using coreutils binaries either built from sources or installed
from the Porting And Archive Centre for HP-UX we see errors of the type
below when copying (cp), listing (ls), or moving (mv) files or
directories on Quantum's StorNext file system (cvfs). When we build
"--without-acl" we do not see these errors.
> mv SEG_5_1* ~/release-input/dev-to-integration
mv: preserving permissions for
`/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
Unknown error (252)
...
> which mv
mv: aliases to mv -I !*;
> which \mv
/usr/local/coreutils/bin/mv
Patrick M. Callahan
Pat (dot) Callahan (at) gd-ais (dot) com
General Dynamics Advanced Information Systems
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 27 Apr 2010 15:12:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 6053 <at> debbugs.gnu.org (full text, mbox):
On 27/04/10 14:43, Callahan, Patrick M. wrote:
> When using coreutils binaries either built from sources or installed
> from the Porting And Archive Centre for HP-UX we see errors of the type
> below when copying (cp), listing (ls), or moving (mv) files or
> directories on Quantum's StorNext file system (cvfs). When we build
> "--without-acl" we do not see these errors.
>
>> mv SEG_5_1* ~/release-input/dev-to-integration
> mv: preserving permissions for
> `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
> Unknown error (252)
It seems the file system is returning that which we're dutifully reporting.
An strace or equivalent would be informative.
Also the version of coreutils you're using would be good to note
(8.5 was just released).
cheers,
Pádraig.
Added tag(s) moreinfo.
Request was from
Bob Proulx <bob <at> proulx.com>
to
control <at> debbugs.gnu.org
.
(Thu, 06 May 2010 02:07:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 08 Jun 2010 00:11:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 6053 <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote:
> Callahan, Patrick M. wrote:
> > When using coreutils binaries either built from sources or installed
> > from the Porting And Archive Centre for HP-UX we see errors of the type
> > below when copying (cp), listing (ls), or moving (mv) files or
> > directories on Quantum's StorNext file system (cvfs). When we build
> > "--without-acl" we do not see these errors.
> >
> >> mv SEG_5_1* ~/release-input/dev-to-integration
> > mv: preserving permissions for
> > `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
> > Unknown error (252)
>
> It seems the file system is returning that which we're dutifully reporting.
> An strace or equivalent would be informative.
> Also the version of coreutils you're using would be good to note
> (8.5 was just released).
On HP-UX the tool 'tusc' (trace unix system call) is the equivalent
tool to 'strace'. Using it you should be able to see the underlying
system calls and their status returns. That would provide a valuable
clue as to where the problem lies.
You are using a combination of operating system and filesystem that
isn't very commonly seen. Nor is it available to the developers
here. You may very well have found a bug. But is the bug in
coreutils mv or in the filesystem or in the kernel? Any of those are
almost equally likely possibilites. And not having such a system to
try it means that we will need to rely upon you to help.
Bob
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 08 Jun 2010 17:29:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 6053 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Bob,
Thanks for responding. One thing I probably did not make clear is that I've tried 8.5 both depots and sources from the "HP Porting and Archive Centre" (http://hpux.connect.org.uk/). I realize that changes they make are out of your control however for a sysadmin like me they make my job easier in our heterogeneous environment.
I started to trace through the code and it seems that the problem is that getacl fails on our StorNext File System cvfs (aka snfs) does not support the getacl call. I could easily accept better warnings when using cp or mv across file systems where acls are not supported on both but the problem is that we see the problems with other commands such as ls -l. Tusc output for an ls is attached and you can see that it is the getacl call that fails.
Patrick M. Callahan Senior Engineer
pat.callahan <at> gd-ais.com
General Dynamics Advanced Information Systems
10467 White Granite Drive Ste 304
Oakton VA 22124
work: 703.277.1471
-----Original Message-----
From: Bob Proulx [mailto:bob <at> proulx.com]
Sent: Monday, June 07, 2010 8:10 PM
To: Callahan, Patrick M.; 6053 <at> debbugs.gnu.org
Subject: Re: bug#6053: cp, ls, and mv bug: unknown error (252)
Pádraig Brady wrote:
> Callahan, Patrick M. wrote:
> > When using coreutils binaries either built from sources or installed
> > from the Porting And Archive Centre for HP-UX we see errors of the type
> > below when copying (cp), listing (ls), or moving (mv) files or
> > directories on Quantum's StorNext file system (cvfs). When we build
> > "--without-acl" we do not see these errors.
> >
> >> mv SEG_5_1* ~/release-input/dev-to-integration
> > mv: preserving permissions for
> > `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
> > Unknown error (252)
>
> It seems the file system is returning that which we're dutifully reporting.
> An strace or equivalent would be informative.
> Also the version of coreutils you're using would be good to note
> (8.5 was just released).
On HP-UX the tool 'tusc' (trace unix system call) is the equivalent
tool to 'strace'. Using it you should be able to see the underlying
system calls and their status returns. That would provide a valuable
clue as to where the problem lies.
You are using a combination of operating system and filesystem that
isn't very commonly seen. Nor is it available to the developers
here. You may very well have found a bug. But is the bug in
coreutils mv or in the filesystem or in the kernel? Any of those are
almost equally likely possibilites. And not having such a system to
try it means that we will need to rely upon you to help.
Bob
[252_error.txt (text/plain, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 08 Jun 2010 20:52:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 6053 <at> debbugs.gnu.org (full text, mbox):
Callahan, Patrick M. wrote:
> Pádraig Brady wrote:
>> Callahan, Patrick M. wrote:
>> > When using coreutils binaries either built from sources or installed
>> > from the Porting And Archive Centre for HP-UX we see errors of the type
>> > below when copying (cp), listing (ls), or moving (mv) files or
>> > directories on Quantum's StorNext file system (cvfs). When we build
>> > "--without-acl" we do not see these errors.
>> >
>> >> mv SEG_5_1* ~/release-input/dev-to-integration
>> > mv: preserving permissions for
>> > `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
>> > Unknown error (252)
Thanks for the details.
Do you care about ACLs?
If not, then building --without-acl should be fine.
If you do require that ACLs be preserved in general,
then more work will be required. The code in question is
probably part of gnulib, in copy-acl.c. There, we already
ignore failure due to conditions that imply lack of support:
if ((errno == ENOSYS || errno == EOPNOTSUPP)
...
if ((errno == ENOSYS || errno == EINVAL || errno == ENOTSUP)
But that the errno value in question, 252, does not map
to a strerror string is ominous. Could it be that your version
of HP-UX's C library is lacking patches that might provide that?
You could get in a debugger and determine where
to add "|| errno == 252" to solve what appears to be
an HP-UX-and/or-cvfs-specific problem.
However, such a change is not appropriate for others,
and I doubt it will be worthwhile to attempt an
upstream workaround.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 08 Jun 2010 22:26:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 6053 <at> debbugs.gnu.org (full text, mbox):
On 08/06/10 21:51, Jim Meyering wrote:
> Callahan, Patrick M. wrote:
>> Pádraig Brady wrote:
>>> Callahan, Patrick M. wrote:
>>>> When using coreutils binaries either built from sources or installed
>>>> from the Porting And Archive Centre for HP-UX we see errors of the type
>>>> below when copying (cp), listing (ls), or moving (mv) files or
>>>> directories on Quantum's StorNext file system (cvfs). When we build
>>>> "--without-acl" we do not see these errors.
>>>>
>>>>> mv SEG_5_1* ~/release-input/dev-to-integration
>>>> mv: preserving permissions for
>>>> `/usr/people/archive/release-input/dev-to-integation/SEG_5_1.txt':
>>>> Unknown error (252)
>
> Thanks for the details.
> Do you care about ACLs?
> If not, then building --without-acl should be fine.
>
> If you do require that ACLs be preserved in general,
> then more work will be required. The code in question is
> probably part of gnulib, in copy-acl.c. There, we already
> ignore failure due to conditions that imply lack of support:
>
> if ((errno == ENOSYS || errno == EOPNOTSUPP)
> ...
> if ((errno == ENOSYS || errno == EINVAL || errno == ENOTSUP)
>
> But that the errno value in question, 252, does not map
> to a strerror string is ominous. Could it be that your version
> of HP-UX's C library is lacking patches that might provide that?
>
> You could get in a debugger and determine where
> to add "|| errno == 252" to solve what appears to be
> an HP-UX-and/or-cvfs-specific problem.
>
> However, such a change is not appropriate for others,
> and I doubt it will be worthwhile to attempt an
> upstream workaround.
Well a quick search says ENOTSUP is 252 on HPUX which is
different to EOPNOTSUPP. So perhaps we need to check
for both these errors in the if statements above.
I've mentioned before about amalgamating various errnos
when testing for "not supported", but it seems dubious
to not treat ENOTSUP and EOPNOTSUPP as synonymous at least.
strerror(252) = "unknown" on HPUX is strange
cheers,
Pádraig.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Thu, 10 Jun 2010 13:24:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 6053 <at> debbugs.gnu.org (full text, mbox):
Thanks for the details.
Do you care about ACLs?
If not, then building --without-acl should be fine.
[>> Right now we don't really care about ACLs and I had already built
[>> the tools as you suggested --without-acl support.
If you do require that ACLs be preserved in general,
then more work will be required. The code in question is
probably part of gnulib, in copy-acl.c. There, we already
ignore failure due to conditions that imply lack of support:
if ((errno == ENOSYS || errno == EOPNOTSUPP)
...
if ((errno == ENOSYS || errno == EINVAL || errno == ENOTSUP)
But that the errno value in question, 252, does not map
to a strerror string is ominous. Could it be that your version
of HP-UX's C library is lacking patches that might provide that?
[>> We are behind in patching our production HP-UX machines and
[>> yes the current C library is quite old. We are likely to go
[>> to HP-UX 11.31 or SLES this summer. The former obsoletes
]>> libc.1 for libc.2.
You could get in a debugger and determine where
to add "|| errno == 252" to solve what appears to be
an HP-UX-and/or-cvfs-specific problem.
However, such a change is not appropriate for others,
and I doubt it will be worthwhile to attempt an
upstream workaround.
[>> Agree. Appreciate the response. Restores my faith in humanity when
[>> I have to spend a lot of times with vendors whose only interest
[>> seems to be to separate me from as much as my budget as they can
[>> get.
Patrick M. Callahan Senior Engineer
pat.callahan <at> gd-ais.com
General Dynamics Advanced Information Systems
10467 White Granite Drive Ste 304
Oakton VA 22124
work: 703.277.1471
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Thu, 10 Jun 2010 13:34:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 6053 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote:
> if ((errno == ENOSYS || errno == EOPNOTSUPP)
> ...
> You could get in a debugger and determine where
> to add "|| errno == 252" to solve what appears to be
> an HP-UX-and/or-cvfs-specific problem.
>
> However, such a change is not appropriate for others,
> and I doubt it will be worthwhile to attempt an
> upstream workaround.
>
> [>> Agree. Appreciate the response. Restores my faith in humanity when
> [>> I have to spend a lot of times with vendors whose only interest
> [>> seems to be to separate me from as much as my budget as they can
> [>> get.
Can you confirm Pádraig's google analysis that 252 is ENOTSUP on your
platform? If we have a symbolic name, then we can patch the code quite
easily. We can also patch the gnulib strerror and perror to detect the
failure to handle ENOTSUP gracefully.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Thu, 10 Jun 2010 14:14:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 6053 <at> debbugs.gnu.org (full text, mbox):
On 10/06/10 14:32, Eric Blake wrote:
> On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote:
>> if ((errno == ENOSYS || errno == EOPNOTSUPP)
>> ...
>> You could get in a debugger and determine where
>> to add "|| errno == 252" to solve what appears to be
>> an HP-UX-and/or-cvfs-specific problem.
>>
>> However, such a change is not appropriate for others,
>> and I doubt it will be worthwhile to attempt an
>> upstream workaround.
>>
>> [>> Agree. Appreciate the response. Restores my faith in humanity when
>> [>> I have to spend a lot of times with vendors whose only interest
>> [>> seems to be to separate me from as much as my budget as they can
>> [>> get.
>
> Can you confirm Pádraig's google analysis that 252 is ENOTSUP on your
> platform? If we have a symbolic name, then we can patch the code quite
> easily. We can also patch the gnulib strerror and perror to detect the
> failure to handle ENOTSUP gracefully.
Perhaps just changing to the more general ACL_NOT_WELL_SUPPORTED()
for HPUX is appropriate? I.E. could you test the following coreutils
patch Patrick?
I left the solaris and cygwin code doing the explicit errno checks,
but suggest they also change to the more general check too.
diff ../gnulib/lib/copy-acl.c gnulib/lib/copy-acl.c
--- ../gnulib/lib/copy-acl.c 2010-03-03 11:23:22.000000000 +0000
+++ gnulib/lib/copy-acl.c 2010-06-10 14:10:19.000000000 +0000
@@ -420,7 +420,7 @@
if (count < 0)
{
- if (errno == ENOSYS || errno == EOPNOTSUPP)
+ if (ACL_NOT_WELL_SUPPORTED (errno))
{
count = 0;
break;
@@ -455,7 +455,7 @@
{
int saved_errno = errno;
- if (errno == ENOSYS || errno == EOPNOTSUPP)
+ if (ACL_NOT_WELL_SUPPORTED (errno))
{
struct stat source_statbuf;
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Mon, 09 Aug 2010 14:47:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 6053 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 06/10/2010 08:12 AM, Pádraig Brady wrote:
> On 10/06/10 14:32, Eric Blake wrote:
>> On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote:
>>> if ((errno == ENOSYS || errno == EOPNOTSUPP)
>>> ...
>>> You could get in a debugger and determine where
>>> to add "|| errno == 252" to solve what appears to be
>>> an HP-UX-and/or-cvfs-specific problem.
>>>
> Perhaps just changing to the more general ACL_NOT_WELL_SUPPORTED()
> for HPUX is appropriate? I.E. could you test the following coreutils
> patch Patrick?
>
> I left the solaris and cygwin code doing the explicit errno checks,
> but suggest they also change to the more general check too.
>
> diff ../gnulib/lib/copy-acl.c gnulib/lib/copy-acl.c
> --- ../gnulib/lib/copy-acl.c 2010-03-03 11:23:22.000000000 +0000
> +++ gnulib/lib/copy-acl.c 2010-06-10 14:10:19.000000000 +0000
> @@ -420,7 +420,7 @@
>
> if (count < 0)
> {
> - if (errno == ENOSYS || errno == EOPNOTSUPP)
> + if (ACL_NOT_WELL_SUPPORTED (errno))
> {
> count = 0;
> break;
> @@ -455,7 +455,7 @@
> {
> int saved_errno = errno;
>
> - if (errno == ENOSYS || errno == EOPNOTSUPP)
> + if (ACL_NOT_WELL_SUPPORTED (errno))
> {
> struct stat source_statbuf;
>
>
I haven't seen any response to this open issue - is this patch still
okay to apply?
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Mon, 09 Aug 2010 15:16:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 6053 <at> debbugs.gnu.org (full text, mbox):
On 09/08/10 15:46, Eric Blake wrote:
> On 06/10/2010 08:12 AM, Pádraig Brady wrote:
>> On 10/06/10 14:32, Eric Blake wrote:
>>> On 06/10/2010 07:22 AM, Callahan, Patrick M. wrote:
>>>> if ((errno == ENOSYS || errno == EOPNOTSUPP)
>>>> ...
>>>> You could get in a debugger and determine where
>>>> to add "|| errno == 252" to solve what appears to be
>>>> an HP-UX-and/or-cvfs-specific problem.
>>>>
>> Perhaps just changing to the more general ACL_NOT_WELL_SUPPORTED()
>> for HPUX is appropriate? I.E. could you test the following coreutils
>> patch Patrick?
>>
>> I left the solaris and cygwin code doing the explicit errno checks,
>> but suggest they also change to the more general check too.
>>
>> diff ../gnulib/lib/copy-acl.c gnulib/lib/copy-acl.c
>> --- ../gnulib/lib/copy-acl.c 2010-03-03 11:23:22.000000000 +0000
>> +++ gnulib/lib/copy-acl.c 2010-06-10 14:10:19.000000000 +0000
>> @@ -420,7 +420,7 @@
>>
>> if (count < 0)
>> {
>> - if (errno == ENOSYS || errno == EOPNOTSUPP)
>> + if (ACL_NOT_WELL_SUPPORTED (errno))
>> {
>> count = 0;
>> break;
>> @@ -455,7 +455,7 @@
>> {
>> int saved_errno = errno;
>>
>> - if (errno == ENOSYS || errno == EOPNOTSUPP)
>> + if (ACL_NOT_WELL_SUPPORTED (errno))
>> {
>> struct stat source_statbuf;
>>
>>
>
> I haven't seen any response to this open issue - is this patch still
> okay to apply?
>
Well without an appropriate system to test on I wouldn't apply it,
though it does seem like it would fix the reported issue.
cheers,
Pádraig.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Mon, 09 Aug 2010 17:51:01 GMT)
Full text and
rfc822 format available.
Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
After applying the patch-I think I have the entire diff-against 8.4 I received the error paraphrasing here unresolved symbol ACL_NOT_WELL_SUPPORTED in ../lib/libcoreutils.a[copy-acl.o]. I quickly forced this define to continue the build. With this change I no longer see the unsupported warnings on an ls.
Patrick M. Callahan Senior Engineer
pat.callahan <at> gd-ais.com<mailto:pat.callahan <at> gd-ais.com>
General Dynamics Advanced Information Systems<http://www.gd-ais.com/>
10467 White Granite Drive Ste 304
Oakton VA 22124
work: 703.277.1471
[Message part 2 (text/html, inline)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Mon, 09 Aug 2010 18:23:02 GMT)
Full text and
rfc822 format available.
Message #43 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 08/09/2010 11:50 AM, Callahan, Patrick M. wrote:
> After applying the patch-I think I have the entire diff-against 8.4 I received the error paraphrasing here unresolved symbol ACL_NOT_WELL_SUPPORTED in ../lib/libcoreutils.a[copy-acl.o]. I quickly forced this define to continue the build. With this change I no longer see the unsupported warnings on an ls.
But ACL_NOT_WELL_SUPPORTED should already be defined in acl-internal.h,
for all but MacOS and Tru64. Oh, maybe I see the problem:
#if USE_ACL
# if HAVE_ACL_GET_FILE
# if defined __APPLE__ && defined __MACH__ /* MacOS X */
# elif defined EOPNOTSUPP /* Tru64 NFS */
# else
# define ACL_NOT_WELL_SUPPORTED(Err) \
((Err) == ENOTSUP || (Err) == ENOSYS || (Err) == EINVAL || (Err) ==
EBUSY)
# endif
# elif HAVE_ACL && defined GETACL /* Solaris, Cygwin, not HP-UX */
...
Sounds like we need to float that definition higher. Just to
double-check, what exactly did you define it to? And can you confirm
what config.h contains for USE_ACL and HAVE_ACL_GET_FILE?
In other words, Pádraig's patch is incomplete until we also tweak
acl-internal.h.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Mon, 09 Aug 2010 21:51:01 GMT)
Full text and
rfc822 format available.
Message #46 received at submit <at> debbugs.gnu.org (full text, mbox):
As a quick "fix" without investigating what is being defined I simply added the line below to copy-acl.c. I make no claim that this is correct.
# define ACL_NOT_WELL_SUPPORTED(Err) \
((Err) == ENOTSUP || (Err) == ENOSYS || (Err) == EINVAL || (Err) == EBUSY)
Patrick M. Callahan Senior Engineer
pat.callahan <at> gd-ais.com
General Dynamics Advanced Information Systems
10467 White Granite Drive Ste 304
Oakton VA 22124
work: 703.277.1471
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Mon, 09 Aug 2010 22:08:02 GMT)
Full text and
rfc822 format available.
Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 08/09/2010 03:50 PM, Callahan, Patrick M. wrote:
> As a quick "fix" without investigating what is being defined I simply added the line below to copy-acl.c. I make no claim that this is correct.
>
> # define ACL_NOT_WELL_SUPPORTED(Err) \
> ((Err) == ENOTSUP || (Err) == ENOSYS || (Err) == EINVAL || (Err) == EBUSY)
But _where_ did you add it, in relation to all the other preprocessor
statements? A context diff would be best, but even knowing the line
number would be helpful in this case.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Tue, 10 Aug 2010 15:37:01 GMT)
Full text and
rfc822 format available.
Message #52 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 08/09/2010 04:07 PM, Eric Blake wrote:
> On 08/09/2010 03:50 PM, Callahan, Patrick M. wrote:
>> As a quick "fix" without investigating what is being defined I simply added the line below to copy-acl.c. I make no claim that this is correct.
>>
>> # define ACL_NOT_WELL_SUPPORTED(Err) \
>> ((Err) == ENOTSUP || (Err) == ENOSYS || (Err) == EINVAL || (Err) == EBUSY)
>
> But _where_ did you add it, in relation to all the other preprocessor
> statements? A context diff would be best, but even knowing the line
> number would be helpful in this case.
On re-reading your mail, I saw that you added it to copy-acl.c rather
than acl-internal.h; my proposed patch merely made it unconditional at
the start of acl-internal.h, so I have now pushed it.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
:
bug#6053
; Package
coreutils
.
(Sun, 12 Jun 2011 23:19:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 6053 <at> debbugs.gnu.org (full text, mbox):
Pádraig Brady wrote on 2010-06-10, and Eric committed the patch on 2010-08-10:
> I left the solaris and cygwin code doing the explicit errno checks,
> but suggest they also change to the more general check too.
>
> diff ../gnulib/lib/copy-acl.c gnulib/lib/copy-acl.c
> --- ../gnulib/lib/copy-acl.c 2010-03-03 11:23:22.000000000 +0000
> +++ gnulib/lib/copy-acl.c 2010-06-10 14:10:19.000000000 +0000
> @@ -420,7 +420,7 @@
>
> if (count < 0)
> {
> - if (errno == ENOSYS || errno == EOPNOTSUPP)
> + if (ACL_NOT_WELL_SUPPORTED (errno))
> {
> count = 0;
> break;
> @@ -455,7 +455,7 @@
> {
> int saved_errno = errno;
>
> - if (errno == ENOSYS || errno == EOPNOTSUPP)
> + if (ACL_NOT_WELL_SUPPORTED (errno))
> {
> struct stat source_statbuf;
Sorry for not having reviewed this patch earlier. If getacl() can return
errno = ENOTSUP, there are 4 files which need to be updated, not just one.
And one of them is tests/test-sameacls.c, which is not supposed to include
"acl-internal.h". So in order to treat all 4 files consistently, it's
better to not use ACL_NOT_WELL_SUPPORTED. I'm applying this followup to your
fix:
2011-06-12 Bruno Haible <bruno <at> clisp.org>
acl: Complete the 2010-08-10 fix.
* lib/file-has-acl.c (file_has_acl) [HP-UX]: Also test against ENOTSUP.
* lib/set-mode-acl.c (qset_acl) [HP-UX]: Likewise.
* lib/copy-acl.c (qcopy_acl) [HP-UX]: Test for the errno values
explicitly.
* tests/test-sameacls.c (main) [HP-UX]: Also test against ENOTSUP.
Reported in <http://debbugs.gnu.org/db/60/6053.html>.
--- lib/copy-acl.c.orig Mon Jun 13 01:02:37 2011
+++ lib/copy-acl.c Mon Jun 13 01:00:19 2011
@@ -420,7 +420,7 @@
if (count < 0)
{
- if (ACL_NOT_WELL_SUPPORTED (errno))
+ if (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP)
{
count = 0;
break;
@@ -455,7 +455,7 @@
{
int saved_errno = errno;
- if (ACL_NOT_WELL_SUPPORTED (errno))
+ if (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP)
{
struct stat source_statbuf;
--- lib/file-has-acl.c.orig Mon Jun 13 01:02:37 2011
+++ lib/file-has-acl.c Mon Jun 13 01:02:19 2011
@@ -527,7 +527,15 @@
count = getacl (name, 0, NULL);
if (count < 0)
- return (errno == ENOSYS || errno == EOPNOTSUPP ? 0 : -1);
+ {
+ /* ENOSYS is seen on newer HP-UX versions.
+ EOPNOTSUPP is typically seen on NFS mounts.
+ ENOTSUP was seen on Quantum StorNext file systems (cvfs). */
+ if (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP)
+ return 0;
+ else
+ return -1;
+ }
if (count == 0)
return 0;
--- lib/set-mode-acl.c.orig Mon Jun 13 01:02:37 2011
+++ lib/set-mode-acl.c Mon Jun 13 01:00:19 2011
@@ -432,7 +432,7 @@
ret = setacl (name, sizeof (entries) / sizeof (struct acl_entry), entries);
if (ret < 0)
{
- if (errno == ENOSYS || errno == EOPNOTSUPP)
+ if (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP)
return chmod_or_fchmod (name, desc, mode);
return -1;
}
--- tests/test-sameacls.c.orig Mon Jun 13 01:02:37 2011
+++ tests/test-sameacls.c Mon Jun 13 01:00:19 2011
@@ -360,10 +360,12 @@
int count2;
count1 = getacl (file1, 0, NULL);
- if (count1 < 0 && (errno == ENOSYS || errno == EOPNOTSUPP))
+ if (count1 < 0
+ && (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP))
count1 = 0;
count2 = getacl (file2, 0, NULL);
- if (count2 < 0 && (errno == ENOSYS || errno == EOPNOTSUPP))
+ if (count2 < 0
+ && (errno == ENOSYS || errno == EOPNOTSUPP || errno == ENOTSUP))
count2 = 0;
if (count1 < 0)
--
In memoriam Medgar Evers <http://en.wikipedia.org/wiki/Medgar_Evers>
Added tag(s) fixed.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 15 Oct 2018 18:09:01 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
6053 <at> debbugs.gnu.org and "Callahan, Patrick M." <pat.callahan <at> gd-ais.com>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 15 Oct 2018 18:09:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 13 Nov 2018 12:24:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 137 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.