in reply to Win32::FileSecurity and File Permission flubs

I don't have Windows to be able to test your code at all, but looking at it, I wonder whether setRights is going to get called for each directory.

It looks like you wanted to loop over directories and call it for every directory, but you didn't.

Another tip. There is no reason to put a use inside a subroutine. The functions that it imports are imported into your package, and therefore are not just limited to the subroutine. Since that is what is happening, it is good to put your use declarations at the top of your file where it is easy to see them all in a hurry.

  • Comment on Re: Win32::FileSecurity and File Permission flubs

Replies are listed 'Best First'.
Re: Re: Win32::FileSecurity and File Permission flubs
by banesong (Acolyte) on Dec 04, 2003 at 16:48 UTC
    Actually, it does loop thru the directories, I just didn't include all 1600+ lines of the code. I inherited this code from someone else, and haven't cleaned up all of the use declaration. Also, I am curious..... According to the documentation, it looks like Win32::FileSecurity is mainly intended for directories? It looks like you can only apply Full Control to files? Do you happen to know if this is true?
      I have no idea about the finer points of Windows file permissioning. I haven't touched Windows in the better part of a month, and I haven't used it for anything serious in over half a year.

      As for the code, if you have 1600+ lines, my suggestion is to try to write a small working snippet to test out what the module can and cannot do. The odds are reasonably good that your fundamental problem is somewhere else in the 1600+ lines, in which case what you have to do is to prove to yourself how that section is supposed to work, that it should work, and then trace backwards through, "If this is right coming into here then it will work correctly because..." until you find the mistake.

      Don't debug the whole program at first. Write a small snippet, test it, and figure out how to make that work. Then work out from there.

      Random tip. I've found with programs of that length that if they don't use strict.pm, then they often have several subtle bugs lurking where someone clearly meant to type in one variable name and accidentally typed another. This is common enough that I've found it a good strategy to add that and fix everything that it complains about. You'll probably fix several bugs pretty easily, and the one that you are working on may be among them...