Re: [Gnump3d-users] Empty playlist generated

[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!


-- 
View this message in context: 
http://www.nabble.com/Empty-playlist-generated-tp20275228p20364358.html
Sent from the GnuMP3D - Users mailing list archive at Nabble.com.