Recursively replace characters in all file and folder names Sharepoint restrict

[questorfla]

I have a need for a quick and easy way to scan all file and folder NAMES within a directory to replace all instances on one character with another.  There are several possibilities, all of them are on the "invalid for use"   by  SharePoint" list.  
The reason for this being doing after the fact is that the collection of files and folders was created before we were using SharePoint and this problem kind of hit me by surprise.   Only when I had repeated failures of a number of files did I check to see the problem.  There are over 50,000 files and one of the "invalid characters" is "#" which appears in over a hundred filenames alone.   If I had checked beforehand, we might not have moved everything to the Office 365 Setup but hindsight being 20/20 doesn't help now.        
Searching for solutions brought up several possibilities, one of which is linked below.  RR.exe at nicj.net (is already compiled) but I don't think it is recursive.

I was wondering if anyone else had ever run into this problem and maybe already has a solution.  If I have to run a script for each character to be replaced, then that is what I will have to do.  Since these filenames are already listed in the database software, I have to try to standardize my replacements so that when a Search looks for a file with a "#" in the name, I have to have a preset replacement list to provide people.
Instead of "&" the filename will have the entire word "and" and so on.  "#" I was going to replace with "-"  but any suggestions appreciated.  SharePoint has a list of maybe 20 characters that can never be used and most never would be.  
But some..... "?"   ????     OR   <<<<  (for that matter "<" or ">"     )   None of these can be used and if they were I have to replace them with something or the files will not Sync.


          This is the best I have found and I don't think it is recursive.

NOTE!  The "Duh" factor just set in  !  Still not a complete solution and I am playing with the other "normal" ways but "dir *#*.*" when run from the top directory level does return valid instances of the improper files so I suppose "ren" might work as well?

 

[skwire]

If I have to run a script for each character to be replaced, then that is what I will have to do.

-questorfla (July 06, 2014, 11:00 PM)

One of my absolute favourite renamers is ReNamer because it allows you to build out a list of steps to take when renaming files.  So, you could make a step-by-step list of rules to make the changes you need.  It has full preview mode so you can be certain exactly what's going to change to what.

I just had a look at the author's website and he's changed up the older fully-featured version to a Lite/Pro license model.  The Lite version is limited to five rules but it ought to be enough to see if you and the application will get along.    Then, you can decide if you want to buy it (it's only ~$20).  I have an older, unlimited version but I'm going to go ahead and buy the new version.

[questorfla]

This is too much thinking for a Sunday night.  It was just my "Luck?" that I happened to test the dir example with what may be the ONLY character that can be stated as >>   *#*.*"  <<<  and NOT get either ran error or nothing at all.     . 
Of course can't search for "&" that way and probably half the others I need to fix.

And "Ren"      Not Gonna Happen!

I suppose it IS going to require some kind of script but the RR.exe (which is hosted on GitHub with the "recursive" option "/r" won't fly.  Or wouldn't for me.  Maybe I cant stack the "/p" (for pretend) option wit /r but
there are few enough files I don't mind being asked if it is OK on every one rather than risk a massive rename that fouls up the entire database   

Hopefully someone has gotten more rest this 4th weekend and has a clearer focus than I do

[lanux128]

Bulk Rename Utility seems worth a try. check out the Mini-Review by [user]zridling[/user].

[questorfla]

Has anyone here used BTSYNC for a multi-user Massive file sync program?  I have used it for some rime and overall I would have to say it does a perfect job.  Bu I am only using it on 4 or 5 systems to keep all my files available where ever and on whatever system  I happen to be using.

I tested it on the whole 50,000 file directory and while not the Fastest, it was not bad and Free to boot

I was thinking through the logic on the program and wondered what would happen if two different people made different modifications to the same file and then BTsync got ahold of them both.

What would be best would be to have both modifications show up as a (1) and a (2) modified version  I guess 2nd best would be first one in to be the change made BUT a notice would be sent to the other person for that person to add their modification as well if needed..
BT SYNC is an interesting solution for people who need to all share the same files but I am not sure how well it works with multiple users/editors.

Another thing I wondered was if there is a file that exists in 10 put of 15 users' SYNC folder and if all users are sharing the same Secret will it propagate to the other users any faster that if there were only 5 users who had it and had to upload to maybe 10 who did not?  Does it get to the others faster if more people are send parts?

With so may Small files it seemed t me the best way to make sure everyone had instant access to everything was to set aside a small 20 GB partition ad just let BY sync keep all their local partitions up to date.

But that is too ay so there has to be something wrong with that idea   Though I have been Impressed so far with BT Sync for my own needs.

[lanux128]

i also wanted to suggest 1-4a rename but too bad it doesn't do folders.

though plenty of usage examples here.

[4wd]

Maybe overkill but when I have files/dirs I can't rename/delete due to weird characters, I usually boot into a Linux LiveCD and fix things.

One of the guys here could probably knock up a perl/bash script if you provide before/after examples of the names.

[40hz]

I was thinking through the logic on the program and wondered what would happen if two different people made different modifications to the same file and then BTsync got ahold of them both.

-questorfla (July 07, 2014, 02:00 AM)

Whatever rules you set up for the sync priority would apply. Usually the last time/date modified prevails by default. Otherwise it would be whichever source folder was given priority if both copies were modified since the last sync.

If multiple users updating the "same" file in two different locations becomes a concern, the only real way to deal with that problem is to go with a version control (i.e. Git et al.) approach. If you were to go that route, a separate sync wouldn't be necessary because the VC software would handle replication and synchronization automatically. With version control all your users would effectively be working off the same copy of the file.

It would, however, create some additional steps for the users when accessing or writing a file. And using version control is something many people have trouble getting their head around. So unless the scenario you described is actually occurring, it's probably not wise to employ VC.

[questorfla]

All the answers were Great!      And from  most of the usual people.     I really appreciate your comments and learn as much from the ones that are not exactly what I need as I do from the ones that ARE!  That makes it hard to pick any one as the "best" answer.  They are all good answers in one way or another.

After spending far too much time on the Microsoft Forums with the same questions (As well as just trying to use only the files that fit their "allowed parameters" ) I discovered to my dismay (but not unexpectedly) that I was at the end of a long line of people who had come before me with their own SharePoint needs and every one of them (more or less) said the REAL solution is "DON'T even THINK  about it!"

People far better than I am offered exactly that suggestion in more than one thread.  (Not the MS techs of course).
Needless to say, I went with my usual "go ahead and hit your finger with the hammer" approach just to be sure it would "hurt"! 
 
It did.

Now i can see why so many warned me off.  The problem with the "unsupported" characters would be just the beginning of a long line of "horror-stories".  As soon as you meet one requirement you find the next one you didn't expect.  Not the least of which was the fact that is is extremely difficult to tell the difference between a "real, physical, file on my drive" from a SharePoint "sym-link" to same file on some MS server.
Then there is the issue of speed.  I won't even go there.  Watching 50,000 files try to stay in sync is.... Well, it has to be some form of real torture.  I could do them faster with X-copy at a command line.

So now I have to clean up the mess SharePoint Testing created.  I will post that separately as the topic is slightly different and may help someone else one day.