Page 1 of 1

Bulk Rename Here scanning folders There & UNC

PostPosted: Tue May 10, 2016 9:59 am
by eNowak
I started using BRU yesterday in a migration project to bulk-edit unwanted characters out of a mass of files, ordered by year. Every year has about 1000 subfolders with up to 19.000 file entries. I advanced year-by-year. Processing was fast and as expected, except for 2 year-folders: When flagging 'Subfolders', BRU goes into object search as it did before, but it does not stop at the folder boundary. Instead it extends to C: disk (running through user profiles, only to name one) and even switches to network paths. Oops! Although the search could be stopped with ESC, this might no be the normal behaviour. It was first found on the XP/32 machine, and then on the Windows7/64 box, with the respective year-folders beeing slightly (10%) different.
Except for the 2 year-folders, I have now tidied-up names, and expecting a successful synchronization/move of the data structures.
I have no idea as for the strange scan behaviour. Is this a known issue?
PS: I was using the free version 3.
EN

Re: Bulk Rename Here scanning folders There & UNC

PostPosted: Wed May 11, 2016 3:25 am
by Admin
Hi , Is there a link from within the 2-year folders to the c: disk?

Re: Bulk Rename Here scanning folders There & UNC

PostPosted: Wed May 11, 2016 5:23 am
by eNowak
Yes, there are lots of crosswise links between the year-folders, and definitely a lot of links to other partitions of the same PC (f.ex. to software folders, the desktop, and download libraries). There are also lots of crosswise links between the two systems.

But this is not specific to the 2 year-folders which made BRU flip out. The only difference might be that Win7 is using Junctions, but I did not place any Junctions by myself in the year folders. In fact, the respective folders have often been copied without side-effects via Windows explorer, command line, and synchronisation tools between the two system, an by this way I would have observed that some instance had created junctions. Besides of that, the XP side flips out in the same way.

What makes me suspicious is an additional observation made shortly ago. After BRU has finished the regular scan, there is a pause of some seconds, followed by the scan of the other, irregular, locations C-Partition and //UNC path to the other system. Terminating with ESC and inspecting the ''Sub Dir'' list shows all paths to the //UNC system have lost their 2 first characters and come without the starting "\".

Finally I have to update my post insofar, as the problem has reduced to 1 year-folder. For unknown reasons, the other, "2016", folder could now be processed normally. Here is the statistics is for the larger year-folders: 2013=18733, 2014=20068, 2015=18242(&FlipOut), 2016=7048 objects. This is for the Win7-system, XP will be re-checked "tomorrow".

Perhaps this information is useful for you. In the meantime, I apply this dirty workaround to "2015": I stop the scan when the expected object count is reached and continue with the incomplete list, followed by consistency checks whether editing has worked.

Thx - EN