Skip Menu |

This queue is for tickets about the File-ExtAttr CPAN distribution.

Report information
The Basics
Id: 32680
Status: resolved
Priority: 0/
Queue: File-ExtAttr
People
Owner: richdawe [...] cpan.org
Requestors: rrt [...] sc3d.org
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: 1.07
Fixed in: (no value)

History Show all quoted text
  Sat Jan 26 13:42:32 2008 rrt [...] sc3d.org - Ticket created
Subject: Please make error-reporting consistent
getfattr returns defined/undefined while delfattr returns true/false, for example. In concert with the other bug I filed (32679) about error returns, I suggest that your calls should either return 0/error code, or, if they have some other return value, return undef/return value and set $!.
  Wed Mar 12 18:31:48 2008 rrt [...] sc3d.org - Correspondence added
From: rrt [...] sc3d.org
I've found a specific problem because of this: getfattr can have a problem with the underlying operation not being supported (on Ubuntu something makes xattr calls for posix_acl_access, which on my machine fail), and this should not cause an error to the user, whereas other errors should. Since I have no way to distinguish the cases, having no return code, all I can do in this case is pretend the required attribute was not found.
  Sun Apr 06 05:25:55 2008 richdawe [...] cpan.org - Correspondence added
From: richdawe [...] cpan.org
On Sat Jan 26 13:42:32 2008, rrt wrote: Show quoted text
> getfattr returns defined/undefined while delfattr returns true/false, > for example. In concert with the other bug I filed (32679) about error > returns, I suggest that your calls should either return 0/error code, > or, if they have some other return value, return undef/return value and > set $!.
I've just updated CVS so that it always sets $! with the value of errno from the failed system call. I've only done this for Linux -- I will make similar changes to FreeBSD/Solaris/Mac OS X when I have time. The function return codes are the same as before. I would be grateful if you could test File::ExtAttr CVS, to check that it works the way you want it to: http://sourceforge.net/cvs/?group_id=153116
  Sun Apr 06 05:26:05 2008 The RT System itself - Status changed from 'new' to 'open'
  Sun Apr 06 05:27:49 2008 richdawe [...] cpan.org - Taken
  Sun Apr 06 19:06:58 2008 rrt [...] sc3d.org - Correspondence added
From: rrt [...] sc3d.org
On Sun Apr 06 05:25:55 2008, RICHDAWE wrote: Show quoted text
> On Sat Jan 26 13:42:32 2008, rrt wrote:
> > getfattr returns defined/undefined while delfattr returns true/false, > > for example. In concert with the other bug I filed (32679) about error > > returns, I suggest that your calls should either return 0/error code, > > or, if they have some other return value, return undef/return value and > > set $!.
> > I've just updated CVS so that it always sets $! with the value of errno > from the failed system call. I've only done this for Linux -- I will > make similar changes to FreeBSD/Solaris/Mac OS X when I have time. > > The function return codes are the same as before. > > I would be grateful if you could test File::ExtAttr CVS, to check that > it works the way you want it to: > > http://sourceforge.net/cvs/?group_id=153116
This seems to work fine now: the error code is returned, I return the error code, and the user-space programs (ls &c.) are happy.
  Sat Jul 19 06:46:17 2008 richdawe [...] cpan.org - Correspondence added
Fixed in release 1.08.
  Sat Jul 19 06:46:19 2008 richdawe [...] cpan.org - Status changed from 'open' to 'resolved'