0

I wrote a Perl module MySQL::Admin.

No problems with the installer (Module::Build). If I try to install this on Windows I get the message:

saveSettings
 Permission denied 
 File: C:/strawberry182/cpan/build/MySQL-Admin-0.67-wIbMnp/cgi-bin/config/settings.pl

See the test report for details.

So what is the right "chmod" that a file will be writeable under Windows using Strawberry Perl?

Sinan Ünür
  • 116,958
  • 15
  • 196
  • 339
Dirk Lindner
  • 7
  • 1
  • 3
    (None of `chmod`, `chown` and `/var` make sense in Windows) – ikegami Mar 27 '15 at 16:32
  • 1
    @schwern Take a look at the [test report](http://www.cpantesters.org/cpan/report/256edfb0-6bf6-1014-a093-cec43d05e988) OP mentions. The module or the test script seems to assume Windows is a variant of Unix. – Sinan Ünür Mar 27 '15 at 18:29
  • @Schwern got it. After upvoting your answer, I looked at the code a bit. To the OP, I know you have put a lot of effort into this, but, please `use CGI::Carp qw(fatalsToBrowser);` has no place in a database administration script. – Sinan Ünür Mar 27 '15 at 18:35
  • @ikegami You're right, I misread about the group permissions. – Schwern Mar 27 '15 at 20:10
  • remove "use CGI::Carp qw(fatalsToBrowser);" ? MySQL::Admin is a Web-frontend like phpMyAdmin. You think i should grow it out ? It was mainly for testing, so i comment it out – Dirk Lindner Mar 28 '15 at 17:03

1 Answers1

2

I see in your code a few instances where you're forgetting to close filehandles. Unlike Unix, Windows has automatic, mandatory file locking on open files which can show up as a Permission Denied error when you try to write to a file which is still open. My first suggestion would be to change every use of a global filehandle like open FILE to open my $fh. Using lexical filehandles means they will automatically close when they go out of scope, greatly reducing the problem.

You also no longer need to use gensym to create a lexical filehandle, open my $fh works as far back as 5.6.

You're also failing to check that many of your file commands work. flock, seek, truncate... many of them have no checks. You can add checks to all of them, or you can use autodie to quietly add checks for you, or you can use Path::Tiny which will throw exceptions on failure and has many, many convenient file manipulation methods. Just be sure to add them as dependencies in your configure phase.

Second, using system on anything but $^X (the current Perl executable) is going to be non-portable. Replace all of them with equivalent Perl functions. Again, Path::Tiny will come in handy here.

Third, Windows permissions are fundamentally different from Unix. Things like chown and chmod and executable bits don't really map. Rule of thumb is you generally don't have to concern yourself with file permissions on Windows.

Finally, get yourself a Windows virtual machine, install Strawberry Perl on it, and test your code. Your code is very Unix-centric, and it will be much faster for you to debug the many small problems it has on Windows than to ask questions of a Windows CPAN tester.

Schwern
  • 153,029
  • 25
  • 195
  • 336
  • 1
    "Windows virtual machine, install Strawberry Perl on it." Yes i do but at first i thought there a lot of people how know much more about perl on Windows like I'am .I think i follow your suggestions. thx lze – Dirk Lindner Mar 28 '15 at 17:14
  • @DirkLindner You did the right thing by asking here. As you run into more problems, by all means ask more questions. Having a Windows VM will make your porting process infinitely less frustrating. – Schwern Mar 28 '15 at 17:34