Copying unique but duplicate file names to single folder

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Seeker
    Enthusiast
    • Apr 2008
    • 24

    Copying unique but duplicate file names to single folder

    If this belongs in a different area, please move. Thanks.

    This may go beyond what Beyond Compare is supposed to do, but it is already so close, I just need the last step - and maybe it's "in there".

    I have files named folder.jpg scattered throughout a folder hierarchy. I want to put all of them into one folder. (And yes, the duplicate file name is the issue).

    I select all the folders, filter on *.jpg, tell Beyond Compare to ignore the folders and select all files. Then "Copy to Folder". What I end up with (and I expected this) is a copy of all the jpg files (without the folder.jpg name) and ONE folder.jpg - the last one of course.

    Given the capability of "Copy to Folder" and the obvious fact that when doing so, some files might have the same name, is there some option to keep them unique (yes, you could maintain the folder hierarchy and keep each folder.jpg in a folder of its own) but in just one folder?

    Like how Windows will save as folder.jpg, then rather than overwriting, folder(1).jpg, folder(2).jpg etc.

    (Oh, and as I continue to look - how would MOVE to folder handle this? I'm scared to try - but I'd hope that you wouldn't lose all but one folder.jpg!!!)

    Thanks for any help. Great product! I tried to purchase v3 already, but I can wait till June 30 - thanks for letting us test it. THANKS FOR UNICODE!

    Owner since BEFORE Jan 1, 2007, and willing to pay for a great product.
    Last edited by Seeker; 04-Jun-2008, 10:35 AM.
  • Seeker
    Enthusiast
    • Apr 2008
    • 24

    #2
    Oh, and I could tolerate (be thrilled with?) an option that gave a duplicate filename its foldername to keep it unique; i.e.

    FNAME1
    --- folder.jpg
    FNAME2
    --- folder.jpg

    copies to single folder as fname1-folder.jpg and fname2-folder.jpg

    or any similar mapping, if such a thing exists. But I'm not betting on it.
    Last edited by Seeker; 04-Jun-2008, 10:36 AM.

    Comment

    • Seeker
      Enthusiast
      • Apr 2008
      • 24

      #3
      I just did a test bed - MOVED two identically named files from two folders into a single folder (don't maintain folder hierarchy). Yep - lost one of them!!!!

      Whereas I consider the copy folder - overwriting the files to be problematic - at least I still have them in their original location.

      But when you move them, you LOSE all but one. That's not real cool, even if intended.

      Thoughts?

      Comment

      • Aaron
        Team Scooter
        • Oct 2007
        • 16000

        #4
        This is currently working as expected. To determine otherwise would add a decent amount of pre-processing to this specific scenario (Copy/Move To Folder, remove folder structure, identical names).

        The workflow you are looking to accomplish is not easily handled in BC. The issue comes in that you have to rename the files manually. To do so more easily, I would recommend a Copy To Folder (a temp folder) and preserve the folder structure. Then Flatten Folders (so it shows the list of files) and rename them manually. Then copy again, removing the folders.
        Aaron P Scooter Software

        Comment

        • Seeker
          Enthusiast
          • Apr 2008
          • 24

          #5
          As I initially said, I'm not real surprised this is as intended, I was just "hoping".

          I can do the renaming with something like Better File Rename, I just thought BC might do it, given there IS overwrite and I doubt it will be expected, especially if there are just 2-3 identical names in a long list of names.

          However, I am surprised you do this for "Move to Folder" without warning the user that they are about to lose (maybe many) files that happen to have the same name.
          Last edited by Seeker; 04-Jun-2008, 02:18 PM.

          Comment

          • Lutz
            Veteran
            • Oct 2007
            • 356

            #6
            Hello!

            Yes, overwriting existing files while copy/move to folder should respect 'Folder Confirmation'-settings!

            Then the renaming may be selected by the user in the confirmation dialog (i. e. (1)/parent folder/CRC-String). This also may appear before the action (managing duplicate file names).

            Greetings Lutz

            Comment

            • Seeker
              Enthusiast
              • Apr 2008
              • 24

              #7
              I'm not sure, since your post says "expert", whether you say that confirmation DOES happen based on folder confirmation, or you are saying it SHOULD happen.

              Either way, copy/move to folder does NOT occur based on folder confirmation settings - all of mine are checked, but this overwrite on copy, and overwrite on move (which results in lost files) does NOT appear to follow the confirmation settings, but simply overwrites with no confirmation dialogs.

              Comment

              • Seeker
                Enthusiast
                • Apr 2008
                • 24

                #8
                Looking at file confirmations, I see two that apply for overwrites:

                Confirm overwriting new files

                Confirm replacing files during move

                I have both checked. For copy, the first might not trigger on some copies, but should for other copies.

                As for the move, it seems the second confirmation listed above would have triggered on each overwrite.

                Now, all that said - I understand if this wasn't considered - it appears "copy/move to folder" may be an add on for convenience - since the confirmations appear designed to cover files that were there before action was initiated (otherwise it would say confirm overwriting files vs confirm overwriting newer files) - whereas here, the files to be overwritten appear DURING the action.

                Even so, this overwriting of files during the action is still of concern, and I think you'll get complaints about it if you leave it alone.

                Thanks, still, for a great product.

                Comment

                • Michael Bulgrien
                  Carpal Tunnel
                  • Oct 2007
                  • 1772

                  #9
                  Originally posted by Seeker
                  since your post says "expert"
                  "expert" means he has been around long enough to make over 50 posts.
                  BC v4.0.7 build 19761
                  ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

                  Comment

                  • Seeker
                    Enthusiast
                    • Apr 2008
                    • 24

                    #10
                    Originally posted by Michael Bulgrien
                    "expert" means he has been around long enough to make over 50 posts.

                    And veteran means similar?

                    Maybe that means I won't be a visitor much longer....

                    Comment

                    • Michael Bulgrien
                      Carpal Tunnel
                      • Oct 2007
                      • 1772

                      #11
                      Yes, I think "Veteran" kicks in at 200 posts.
                      BC v4.0.7 build 19761
                      ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

                      Comment

                      • Seeker
                        Enthusiast
                        • Apr 2008
                        • 24

                        #12
                        Originally posted by Michael Bulgrien
                        Yes, I think "Veteran" kicks in at 200 posts.
                        Well, as a veteran - what's your take on this issue? Does it seem ok to you or a problem?

                        Comment

                        • Michael Bulgrien
                          Carpal Tunnel
                          • Oct 2007
                          • 1772

                          #13
                          Since you put me on the spot...I guess I would handle it this way:
                          • Create an empty folder.
                          • Compare the empty folder with the root folder of the folder tree with the folder.jpg files
                          • Set your file filter to: folder.jpg
                          • Click the Expand All button in the toolbar (this should show only the folder.jpg files)
                          • Press Shift+Ctrl+A to select all files
                          • Copy the selected files to the other side

                          At this point, you will have a new folder structure that only has the folder.jpg files. You can expand the folder tree and view it flattened if you wish. You can also write a simple vbScript to iterate through the folder structure and rename the files any way you want. See this post for starters.
                          Hint: You can check oFolder.Subfolders as well as oFolder.Files
                          BC v4.0.7 build 19761
                          ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

                          Comment

                          • Michael Bulgrien
                            Carpal Tunnel
                            • Oct 2007
                            • 1772

                            #14
                            To be more to the point:

                            Windows Explorer does not rename files when you copy them from different locations into the same target location. It only renames a file when you make a copy of it (copying it to the same folder that it is already in). Since BC3 uses the Windows copy API's, it can't really be expected to do anything different.

                            Should BC3 provide a custom method to rename duplicate files? Perhaps. Will it be implemented prior to the initial non-beta release? Not likely. It certainly can go on the wish list for a future enhancement. It might be something that gets implemented when a "Find duplicate files" option gets added to the product.
                            BC v4.0.7 build 19761
                            ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

                            Comment

                            • Seeker
                              Enthusiast
                              • Apr 2008
                              • 24

                              #15
                              Thanks for your input - your first post is what I have already started doing as my current need was immediate (although using Better File Rename vs. a vbScript - but I'll check what you posted out)

                              I'd already accepted that BC3 is not designed to do "what I want" with multiple duplicates and have adjusted.

                              So, really, MY concern has shifted to a more general user "surprise" level if they don't think it through (which we now have).

                              Let's consider a situation (forget my multiple folder.jpg thingie) - a user has, say 127 doc files scattered among 19 folders (don't ask me why, I'm making this up) and they want to consolidate them. Among them are 6 files with duplicate names (3 xyy.doc, 3 yyz.doc, the other 121 are unique)

                              Sure - BC3 isn't really for this, but hey - there's a Copy to Folder/Ignore Folder Structure command.

                              For "Copy to Folder" - I'm not concerned - most users doing this will copy their files, then see "on the left" there are 127 files and "on the right" in one folder are 123 files - they'll go "huh" and figure it out. No loss.

                              But for "MOVE to folder" - no warning - 4 files are LOST.

                              I would say at minimum there should be a box that pops up and describes this situation so that users won't be caught surprised with loss of data.

                              (HEY! I'm a Journeyman!)
                              Last edited by Seeker; 05-Jun-2008, 01:20 PM.

                              Comment

                              Working...