locked
After SyncToy runs rogue .1 files appear. RRS feed

  • Question

  • Trying to sync web directories between servers.

    After SyncToy runs rogue .1 files appear.

     

    Running SyncToy 2.0 beta on Server 2003, in Contribute Mode.

     

    Example.  Server1 is base server and Server2 is server being updated.

     

    Server1\

    www\

    default.aspx

     

    Server2\

    www\

    default.aspx           <-- New Updated File.

    default.1.aspx        <-- Previous Version.  ( SyncToy seems to have renamed previous file )

     

     

    Any Explaination for the .1 files. Would be appreciated.

    Would like to stop the creation of these files.

    It is causing problems on the Web Server when files in the bin directory are doubled up.

    Not to mention the new space requirements.

     

    Thanks.

    Monday, March 17, 2008 11:37 PM

Answers

  • This is covered in our FAQ thread at the top of the forum page. Essentially, you'll get .1, .2, etc files when you make conflicting actions on or or two files on the left and right folders where two essentially different files end up having the same file path and name after the conflicting. Here's a few examples:

     

    - You renamed file A.txt to B.txt on the left and also created a new file named B.txt on the right.

    - You moved the same file on both sides to the same relative location on both sides.

     

    In all of these situations, Synctoy cannot determine the user intent for sure and take the safer option of creating a file with the .1 extension so as to preserve both copies.

     

    Let us know if you figure out a third situation besides the ones listed above where this is happening for you.
    Tuesday, October 14, 2008 8:17 PM
    Answerer

All replies

  • Same here. I just spotted that little .1 file appearing. I cannot quite put my finger on when and how and what I did that lead to its appearance. I was sync'ing a file called Test.txt and a file called Test.1.txt appeared on the left and then got sync'ed to the right. Any idea?

     

    Thanks

     

    Monday, April 14, 2008 6:22 PM
  • Hi,

     

    The .1 ( and you can see .2, .3 files sometimes appear as well) files are created by SyncToy when we think there is a possibility that the files with the same name are actually two different files ( a.k.a. "name collision" ). To avoid any loss of legitimate data - we save the previous version of the file under  a different name so that users can recover these files if they want to. If you are sure that this is the same file and you do not need it - you can safely delete the file.

     

    C_Scarpitto,

    I would suggest deleting your folder pair - then going ahead and deleting all the .1 files and then recreating the folder pair again. This should fix your proablem.

     

    Deepa


    Tuesday, April 15, 2008 9:41 PM
  • Hi,

     

    The .1 ( and you can see .2, .3 files sometimes appear as well) files are created by SyncToy when we think there is a possibility that the files with the same name are actually two different files ( a.k.a. "name collision" ). To avoid any loss of legitimate data - we save the previous version of the file under  a different name so that users can recover these files if they want to. If you are sure that this is the same file and you do not need it - you can safely delete the file.

     

    C_Scarpitto,

    I would suggest deleting your folder pair - then going ahead and deleting all the .1 files and then recreating the folder pair again. This should fix your problem.

     

    Deepa


    Tuesday, April 15, 2008 9:41 PM
  • I have found that this occurs sometimes when you make the same change (like a folder move) on both the source and the target when a folder pair is set to sync. In otherwords, let's say I have this folder structure on both source and target:

     

    /-Web

            |_dot.com

            |_dot.net

     

    Then, on both the source and target, I move the dot.net folder into the dot.com folder, like so:

     

    /-Web

            |_dot.com

                         |_dot.net

     

     

    Then next time you sync, SyncToy 2.x might think there is a collision of files in the dot.net folder, and create the duplicates. For one reason or another (I don't know why but a SyncToy dev might) it doesn't see these folders as being equal anymore.

     

    Cheers,

     

    Toby

    Wednesday, April 16, 2008 4:17 PM
  • It would be nice to disable or force the overwrite on a name collision.

     

    This feature causes problems when sync'ing a web application developed in ASP.NET which contain multiple assemblies.

    It causes fatal error when new assemblies are added to the bin directory in this fashion (.1.)

    Something about having problems loading these false assemblies or finding there dependencies.

     

    Sorry for the vague error message don't have the exact error at the moment.

     

    Thursday, April 17, 2008 2:51 AM
  • Thanks C_Scarpitto - we will keep in mind your suggestion that we allow a configuration where users can configure a forced overwrite.

     

    Deepa

    Thursday, April 17, 2008 5:36 PM
  • I have been having the same problem with the "1" appended to the end of the filename. Unfortunately this has created chaos within my sync'ed folders. I had to go in and delete all of the duplicates. I'm wondering if this is something that 2.0 created. Luckily I have a 1.4 setup file stored away just in case the problem is consistent. In the meantime I've simply been doing everything "manually" by deleting a folder at one end and copying over to the other end. <frustrated grunt>.

    Kind Regards,
    Daniel in Tulsa
    aka siouxdax
    Tuesday, October 14, 2008 1:45 PM
  • This is covered in our FAQ thread at the top of the forum page. Essentially, you'll get .1, .2, etc files when you make conflicting actions on or or two files on the left and right folders where two essentially different files end up having the same file path and name after the conflicting. Here's a few examples:

     

    - You renamed file A.txt to B.txt on the left and also created a new file named B.txt on the right.

    - You moved the same file on both sides to the same relative location on both sides.

     

    In all of these situations, Synctoy cannot determine the user intent for sure and take the safer option of creating a file with the .1 extension so as to preserve both copies.

     

    Let us know if you figure out a third situation besides the ones listed above where this is happening for you.
    Tuesday, October 14, 2008 8:17 PM
    Answerer
  • I'm getting this and my setup is simple.

    All files from C:\Documents are being synced to D:\Documents   It doesn't happen to every single file but every sync duplicates a lot.  It's a major pain going back in to manually delete all the .1 .2 etc.  I setup another sync to E:\Documents and it's happening there too.  I thought maybe it was just that first Echo that had a bug.  And yes, I'm doing ECHO for each.  Seems simple enough, copy files from C: to D:...but copy and paste seems to work better than Sync Toy 2.0.
    Monday, November 10, 2008 11:09 PM
  • Are the duplicate files appearing on the Right folder for the ECHO? Also do you notice any pattern on the files which are getting duplicated? Are these files that are generally being accessed by a particular application, etc?

     

    Thursday, November 13, 2008 2:32 AM
    Answerer
  •  

    "Are the duplicate files appearing on the Right folder for the ECHO? Also do you notice any pattern on the files which are getting duplicated? Are these files that are generally being accessed by a particular application, etc? "

     

    This is actually the idea I had today.  I'm going to try and pinpoint any patterns in files, accessed and the .1 issue.  I know the file aren't changed in any way that I can see (same data and size) but maybe something is leaving a trace so Sync Toy sees something.  I'm not sure, but that's definitely what I'm checking out.  Thanks.

    Thursday, November 13, 2008 6:37 AM
  • OK so how the heck do I remove all the stupid duplicates?
    Tuesday, January 17, 2017 2:41 PM
  • About removing the duplicates - in case this helps anything, this worked for me in Windows 7:

    First, I looked in enough folders - in my case, about 20 of them - to satisfy myself that all the  xxxxxx.1.yyy files they contained were actually duplicates of the original and equivalent  xxxxxx.yyy files.

    Then I clicked on My Documents and in the "search" field, I entered     *.1.*     (the * is a wildcard)

    Almost 3,000 files were listed.  The first 15 or so files didn't have    .1.    in the file name, so maybe they contained   .1.  in their contents (I didn't check.)

    I scrolled through the rest of the files, all of which had   .1.   at the end of the file name before the file extension.

    Then I selected the files with filenames ending in  .1.   and deleted them. 

    I have my fingers crossed and I am not going to empty my recycle bin until I'm pretty sure that I didn't delete anything that I wanted . . 

    Wednesday, November 8, 2017 12:25 AM