Empty playlist generated

[dexterous]

Ver : gnump3d v3.0 [CVS Info: gnump3d2 1.156 (2007/10/16)] on Perl v5.008008

Hello, I recently changed the partition my music archive is located in to use ACL's.  I have modified the permissions at the top level, recursively down my archive as such :

     drwxrws--x+ 37 root share 1.2K 2008-10-26 06:59 /srv/storage/main/music

     # file: .
     # owner: root
     # group: share
     user::rwx
     user:gnump3d:r-x
     group::rwx
     group:share:rwx
     group:gnump3d:r-x
     mask::rwx
     other::--x
     default:user::rwx
     default:user:root:rwx
     default:user:gnump3d:r-x
     default:group::rwx
     default:group:share:rwx
     default:group:gnump3d:r-x
     default:mask::rwx
     default:other::--x

gnump3d is running as gnump3d
     gnump3d   5406  0.0  1.0  36992 16020 ?        Ss   14:27   0:00 /usr/bin/perl -w /usr/bin/gnump3d

getent group share
     share:x:110:saturnine,dextrous
getent group gnump3d
     gnump3d:x:1001:gnump3d

saturnine is my wife, dextrous is myself.  These files are accessible via a samba share so that either my wife and I can manage the music without bumping into access denied errors as would be the case without acls and default permissions.

Everytime I try to generate a playlist, strace reveals this error message:
26767 write(2, "Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/gnump3d/sorting.pm line 149, <GEN62> line 12.\n", 124) = 124'

However, if I access a single file, it generates a working m3u playlist for that single file.  If I run a shell as gnump3d, I can stat all the music, run ls, etc.  If I chmod -R o+r the entire music directory, playlists generate fine, but I am trying to avoid this.

I am guessing that maybe a thread or something is generated that is not run as gnump3d or root, is this possible?  Please let me know if I can provide more information.  Thanks in advance for any help or comments with this. :)

[dexterous]

dexterous wrote:

Ver : gnump3d v3.0 [CVS Info: gnump3d2 1.156 (2007/10/16)] on Perl v5.008008

Hello, I recently changed the partition my music archive is located in to use ACL's.  I have modified the permissions at the top level, recursively down my archive as such :

     drwxrws--x+ 37 root share 1.2K 2008-10-26 06:59 /srv/storage/main/music

     # file: .
     # owner: root
     # group: share
     user::rwx
     user:gnump3d:r-x
     group::rwx
     group:share:rwx
     group:gnump3d:r-x
     mask::rwx
     other::--x
     default:user::rwx
     default:user:root:rwx
     default:user:gnump3d:r-x
     default:group::rwx
     default:group:share:rwx
     default:group:gnump3d:r-x
     default:mask::rwx
     default:other::--x

gnump3d is running as gnump3d
     gnump3d   5406  0.0  1.0  36992 16020 ?        Ss   14:27   0:00 /usr/bin/perl -w /usr/bin/gnump3d

getent group share
     share:x:110:saturnine,dextrous
getent group gnump3d
     gnump3d:x:1001:gnump3d

saturnine is my wife, dextrous is myself.  These files are accessible via a samba share so that either my wife and I can manage the music without bumping into access denied errors as would be the case without acls and default permissions.

Everytime I try to generate a playlist, strace reveals this error message:
26767 write(2, "Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/gnump3d/sorting.pm line 149, <GEN62> line 12.\n", 124) = 124'

However, if I access a single file, it generates a working m3u playlist for that single file.  If I run a shell as gnump3d, I can stat all the music, run ls, etc.  If I chmod -R o+r the entire music directory, playlists generate fine, but I am trying to avoid this.

I am guessing that maybe a thread or something is generated that is not run as gnump3d or root, is this possible?  Please let me know if I can provide more information.  Thanks in advance for any help or comments with this. :)

Well, I've been looking in to this, my perl knowledge is novice at best.
However, I've made myself a fix for this.. maybe someone else can clean it up?

/usr/bin/gnump3d : Line 1499
    next if ( ! -r $file );

For some reason, this test is coming back false even though the files are
readable, I tried changing it to -R with no effect.  So, I commented out that line
and added the following.

   if (!open(TEMP,"<",$file)) {
           print STDERR "Skipped unreadable file : $file \n";
           next;
   }
   close(TEMP);

Works no problem like this.  I don't know if there is a better way to go about it, I hope there is.  Opening a file just to test if it is readable seems wasteful to me.

Once again, Thanks in advance for any input.

[dexterous]

dexterous wrote:

Well, I've been looking in to this, my perl knowledge is novice at best.
However, I've made myself a fix for this.. maybe someone else can clean it up?

/usr/bin/gnump3d : Line 1499
    next if ( ! -r $file );

For some reason, this test is coming back false even though the files are
readable, I tried changing it to -R with no effect.  So, I commented out that line
and added the following.

   if (!open(TEMP,"<",$file)) {
           print STDERR "Skipped unreadable file : $file \n";
           next;
   }
   close(TEMP);

Works no problem like this.  I don't know if there is a better way to go about it, I hope there is.  Opening a file just to test if it is readable seems wasteful to me.

Once again, Thanks in advance for any input.

Looking into this even further, I found the following information at ( http://perldoc.perl.org/functions/-X.html ) :

The interpretation of the file permission operators -r , -R , -w , -W , -x , and -X is by default based solely on the mode of the file and the uids and gids of the user. There may be other reasons you can't actually read, write, or execute the file: for example network filesystem access controls, ACLs (access control lists), read-only filesystems, and unrecognized executable formats. Note that the use of these six specific operators to verify if some operation is possible is usually a mistake, because it may be open to race conditions.

Also note that, for the superuser on the local filesystems, the -r , -R , -w , and -W tests always return 1, and -x and -X return 1 if any execute bit is set in the mode. Scripts run by the superuser may thus need to do a stat() to determine the actual mode of the file, or temporarily set their effective uid to something else.

If you are using ACLs, there is a pragma called filetest that may produce more accurate results than the bare stat() mode bits. When under the use filetest 'access' the above-mentioned filetests will test whether the permission can (not) be granted using the access() family of system calls. Also note that the -x and -X may under this pragma return true even if there are no execute permission bits set (nor any extra execute permission ACLs). This strangeness is due to the underlying system calls' definitions. Note also that, due to the implementation of use filetest 'access' , the _ special filehandle won't cache the results of the file tests when this pragma is in effect. Read the documentation for the filetest pragma for more information.

I undid my previous changes in /usr/bin/gnump3d and added "use filetest 'access'" near the top with the other includes which also resolved my issue, and is possibly cleaner?  It's definitely more simple a change from my point of view which may be a merit in itself?  As always, any feedback is appreciated!