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.

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

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?