in reply to Test for directory entries and exit if certain conditions are met?

C:\Dokumente und Einstellungen is the same as C:\Documents and Settings on an English system. Use of spaces within a filepath is a Microsoft thing. We have to live with that limitation.

Your code should not be managing access to filepaths. The OS does that independent of what your code does or does not do. If you are on Windows and you are normal user, you can't just "do what you want", the OS sets limits on "where you can go", "what you can see" and "what you can do".

I see NO reason for your program to get involved in access permissions.

  • Comment on Re: Test for directory entries and exit if certain conditions are met?

Replies are listed 'Best First'.
Re^2: Test for directory entries and exit if certain conditions are met?
by matze77 (Friar) on Nov 04, 2009 at 08:58 UTC

    Hmm i think i wasnt explaining it well enough ...
    The code is mainly designed for removing illegal characters (todo) and spaces from filenames and directory trees on (documentation base at our fileserver). Example: 

    #A subdir under the documentation base:
v:\sql\
15.07.2008  16:52            38.705 sql datensicherung.pdf
15.07.2008  16:54            32.120 SQL 2000 transaktionsprotokoll ver
+kleinern.pdf

    [download]
    So the code is harmful if started directly from the commandline. So i have either:
    a) Change the code so that it doesnt just work on the current directory as is now. or
    b) Check that it is not used on potential "dangered" directory trees.
    b) Seems to be reasonable for me anyway, since the standard commandline starts at the users home directory (HOMEPATH=\Dokumente und Einstellungen\myuser) on Win32 and colleagues might use my code too without really knowing what it does ...

    Thanks in Advance MH
[reply]
[d/l]
      I still don't quite understand. Is this some issue about moving some existing files between Unix and Windows? Or is the file server Windows also?

      I don't understand complete requirement about the "illegal name". On Windows or on Unix, nobody can create an "illegal file name" for that particular OS, the OS won't let you do it!

      If your computers are set up with user permission levels, there are limits on what users can do. And some users can do more than other users and/or do different things than other users. Windows does this differently than Unix but these kind of mechanisms exist and should be used!

      In general, a user is going to have complete read/write/create/modify permissions on his own files. In general, the user shouldn't have that permission level for other user's files. If a user can do some operation like "delete a file" in Windows Explorer, nothing that you can do in your Perl script is going to prevent that! Your script should be running at the user permission level of the user who started the program. There will be LOT's of files that the user doesn't even have permission to read, meaning he would not even know (and your script running at his permission level) that they were there in the first place, much less be able to modify the file name!

      If you are moving files from Windows to Unix, the file transfer program will report some kind of error with a non-Unix compatible name. The the user fixes it and goes on. Same thing should happen if users are trying to create a file a Unix file system that is mounted to look like a Windows Drive.

      I guess at the end of the day, it sounds like you would like to enforce some "naming conventions" for whatever reason. I guess the reason doesn't even matter.

      I think your approach of making renames "automatically" without user input is wrong.
      (1) How is this poor user going to find his file given that you have renamed it without his knowledge?
      (2) Your methodology will not converge to fewer and fewer errors without user training.

      Sounds like you should be making a report as sys admin that runs once per day or whenever and users get an e-mail about the files that they "own". Make it optional for a user to run the report themselves. Report files that have "spaces", etc. Report should tell user how to correct the problem themselves! Vielleicht hinweise wie: Change "space" to "_", do not use umlaut and do not use use scharf-s...

      If you want a common understanding within the organization, some user training so that these problems don't happen in the first place is a good idea. If the users keep getting these e-mails about file name problems, they will learn how to NOT get these e-mails.

      You want to turn this job of "fixing" into one of "watching/observing and informing".
      Update: you don't want to say after 6 months to the boss: look at how messed up our process and team is and here is how many file naming errors my Perl script has fixed...You want to say: Here is how many fewer errors our team has made over the last 6 months thanks to my Perl admin software! See how we are now preventing errors instead of trying to fix them later?

[reply]

        OK. Again. It is Windows only:
        It is a documentation base with many files and directories that has grown over the years.
        The "users" are only sysadmins. But there is documentation from ex-users which left the company many years ago. So a "user" thought it might be important that this and that file or directory is first in "Explorer View". So he named it e.g. 

         "!!!My Important File/Directory please pay A T T E N T I O N  A L L !
+!!!" or: "%20%My%20%reports%20downloaded%20document%20.pdf"
(Which seems to come from downloaded documents where html is in the 
document name)

        [download]

        As a "new user", which joined the company recently i am asked or commanded ;-) to sort and bring "order" to it., cause this is outdated (it was done back in 2001 e.g.) i want to eleminate those "not illegal" but "hard to read" "file- and directorynames *and afterwards* sort it manually. But i *d o n t* want to do that by hand on thousands of files (namely: Files: 15624 Files 15.810.523.308 Bytes...)
        And yes i want to run the script on a regularly basis and the other sysadmins are informed that maybe some old links are broken, but its no problem ...

        Thanks in Advance MH
[reply]
[d/l]

In Section Seekers of Perl Wisdom