none
.DAT files RRS feed

  • Question

  • Every time I run SyncToy 2.0 I see another .Dat file in the Applications Data folder.

     

    I just uninstalled it and re-installed and see the following:

     

    Directory of C:\Documents and Settings\Jim\Local Settings\Application Data\Microsoft\SyncToy


    2008-08-28  09:11 PM               120 SyncToyAppRuntime-00.DAT
    2008-08-28  09:11 PM               120 SyncToyAppRuntime-01.DAT
    2008-08-28  09:12 PM               120 SyncToyAppRuntime-02.DAT
    2008-08-28  09:13 PM               120 SyncToyAppRuntime-03.DAT
    2008-08-28  09:11 PM               120 SyncToySetup-00.DAT

     

     

    The log file:

    SYNC: 08/28/2008 21:11:26:031: -------------------------------------------------------------------------
    SYNC: 08/28/2008 21:11:26:031: Starting SyncToy, version 2.0.100.0, built 2008-08-12 02:07:12 PM.
    SYNC: 08/28/2008 21:11:56:359: -------------------------------------------------------------------------
    SYNC: 08/28/2008 21:11:56:359: Starting SyncToy, version 2.0.100.0, built 2008-08-12 02:07:12 PM.
    SYNC: 08/28/2008 21:12:18:750: -------------------------------------------------------------------------
    SYNC: 08/28/2008 21:12:18:750: Starting SyncToy, version 2.0.100.0, built 2008-08-12 02:07:12 PM.
    SYNC: 08/28/2008 21:13:09:250: -------------------------------------------------------------------------
    SYNC: 08/28/2008 21:13:09:250: Starting SyncToy, version 2.0.100.0, built 2008-08-12 02:07:12 PM.
    SYNC: 08/28/2008 21:13:51:765: -------------------------------------------------------------------------
    SYNC: 08/28/2008 21:13:51:765: Starting SyncToy, version 2.0.100.0, built 2008-08-12 02:07:12 PM.

     

    I did not run any syncs, just started and stopped it.

     

    There were a great many files in the applications folder and the 2.0 directory - very large files.

     

    I deleted them after the uninstall except for the

    SyncToyPairs.bin file.

     

     

     

     

    Friday, August 29, 2008 4:20 AM

Answers

  • These are temporary files that are created for anonymous feedback reporting to Microsoft regarding your SyncToy experience (you need to OPT IN for this). SyncToy periodically deletes these files automatically. If you want to avoid these files, go to the Customer Feedback Options in the SyncToy Help menu and turn it off. After you have done that, you can delete any remaining .DAT files.  Please ONLY delete files that are named as follows:

     

     SyncToyAppRuntime*.DAT
     SyncToyFolderPairModification*.DAT
     SyncToySetup*.DAT
     SyncToySyncOperation*.DAT

     

    Tuesday, September 2, 2008 4:10 AM
    Answerer

All replies

  • In addition to the above .DAT files, there are also files for every run

    in the folder pairs.

     

    The current run file is not hidden, older runs have the .dat file hidden.

    Friday, August 29, 2008 4:32 AM
  • Would it be possible to make a link (shortcut)

    from

     

    ...\Local Settings\Application Data\Microsoft\SyncToy\2.0

     

    to another mount point?

     

    I could move this data off my system drive and move it to some

    scratch area so I can clean it periodically.

     

     

    Friday, August 29, 2008 1:36 PM
  • These are temporary files that are created for anonymous feedback reporting to Microsoft regarding your SyncToy experience (you need to OPT IN for this). SyncToy periodically deletes these files automatically. If you want to avoid these files, go to the Customer Feedback Options in the SyncToy Help menu and turn it off. After you have done that, you can delete any remaining .DAT files.  Please ONLY delete files that are named as follows:

     

     SyncToyAppRuntime*.DAT
     SyncToyFolderPairModification*.DAT
     SyncToySetup*.DAT
     SyncToySyncOperation*.DAT

     

    Tuesday, September 2, 2008 4:10 AM
    Answerer
  •  

    I have not opted in.

     

    The SyncToy help page on Customer Experience Improvement Program has the

    "No" box marked.

     

     

    Friday, September 5, 2008 1:57 PM
  • This is the data in the config file - is it appropriate?

     

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <system.diagnostics>
        <switches>
          <add name="SyncToyTraceLevel" value="Info" />
        </switches>
      </system.diagnostics>
    </configuration>

    Saturday, September 6, 2008 1:11 AM
  •  

    I was able to use 'linkd' to make a symbolic link from

    C:\Documents and Settings\Jim\Local Settings\Application Data\Microsoft\SyncToy

     

    to

     

    E:\SyncToy

     

    where things appear to be working.

     

    Synctoy has been running for over 2 hours using about 35 minutes of CPU time.

     

    My main concern about SyncToy is it's incredible ability to generate fragmented files.

     

    Most of the .dat files that have been built in these 2 hours are fragmented into over

    500 parts on a clean defragmented partition. I can't imagine the chaos this will make on

    the typical user's sole C Drive.

     

    The Windows Desktop Search also has this same ability to fragment, and it's no coincidence

    that I put SyncToy's support files in the same partition.

     

     

     

     

     

    Sunday, September 7, 2008 4:08 PM
  • THis has been going on for 7:15 hours:min now... It doesn't look like much is happening...

    Here are some stats:

     

    |Process||PID||% CPU| |Time| |Sw/s| |InMem KB||Private KB||Total KB||Th||Pri|       
     SyncToy  564  4.68%  48:49    395     18,200      29,120   184,220  10  Norm  
            
    |Hndls| |Wndws| |USER| |GDI| |Up Time|      |Reads|    |Read KB| |Rd Rate B/s| 
       429    102     121   118    7:15:51   18,698,150   74,791,985     1,619,968 
     
      |Writes|   |Write KB| |Wr Rate B/s| |Path|
     3,211,443   12,845,413       317,440 C:\Program Files\SyncToy 2.0\SyncToy.exe

     

    Sunday, September 7, 2008 9:22 PM
  •  

    Now going on 8.5 hours and still running.

     

    I can see that each folder is taking about a minute of processing, but I have no idea

    why things are running so slowly.

     

    Nothing else is running on my system: 4 GB of RAM. 2.2 GHz dual core.

     

    Here is the active thread's current stack:


    Thread Start Address:                                                         
    Symbol Name:                                         Line Number:           PC:
    mscorwks ! ClrCreateManagedInstance() + 0x8aa4       ------            79F959E8
                                                                                  
    Thread Stack::                                                                
    Symbol:                                              Line Number:           PCTongue Tiedtack Frame:
    ntdll ! _KiFastSystemCallRet@0() + 0x0               ------            7C90E4F43EED778
    ntdll ! _NtQueryAttributesFile@8() + 0xc             ------            7C90D6FC3EED77C
    KERNEL32 ! _GetFileAttributesW@4() + 0x79            ------            7C80B8433EED7EC
    FileSyncProvider ! DllGetClassObject() + 0x687c      ------            2900B0EB3EEDC64
    FileSyncProvider ! DllGetClassObject() + 0x1915      ------            290061843EEE50C
    FileSyncProvider ! DllGetClassObject() + 0x3cca      ------            290085393EEE5A4
    FileSyncProvider ! DllGetClassObject() + 0x3f14      ------            290087833EEE63C
    FileSyncProvider ! DllGetClassObject() + 0x3f14      ------            290087833EEE6D4
    FileSyncProvider ! DllGetClassObject() + 0x3f14      ------            290087833EEE76C
    FileSyncProvider ! DllGetClassObject() + 0x3f14      ------            290087833EEE804
    FileSyncProvider ! DllGetClassObject() + 0x4d8c      ------            290095FB3EEEA88
    FileSyncProvider ! DllGetClassObject() + 0x527c      ------            29009AEB3EEEB1C
    mscorwks ! LogHelp_TerminateOnAssert() + 0x12b2      ------            79E7A5CA3EEEB3C
    mscorwks ! LogHelp_TerminateOnAssert() + 0x3433      ------            79E7C74B3EEEB50
    mscorwks ! LogHelp_TerminateOnAssert() + 0x33b4      ------            79E7C6CC3EEEBD0
    mscorwks ! TranslateSecurityAttributes() + 0x2491c   ------            7A17AA453EEECCC
    mscorwks ! TranslateSecurityAttributes() + 0x24c8f   ------            7A17ADB83EEF078
    mscorlib.ni + 2BCEB8                                 ------            7937CEB83EEF11C
    mscorlib.ni + 414B39                                 ------            794D4B393EEF130
    mscorlib.ni + 347CAA                                 ------            79407CAA3EEF134
    mscorlib.ni + 2B3ECD                                 ------            79373ECD79407CAA

    Sunday, September 7, 2008 10:41 PM
  •  

    Now at almost 11 hours running and almost 1 hour of CPU time I can see that I'm not

    going to get much work done today, so I may as well let it run all night.

     

    The green progress bar hasn't moved in the last hour, but folder names crawl by.

     

    I probably didn't mention that this is a 'Preview' run. It isn't even updating any files.

     

    I only anticipated making a test of the linkd-created folder. I wonder if that symlink

    is he cause of all this? Are open files handles inpacted by being on a symlink?

    Doesn't seem likely to me, but  can't explain any of this behavior.

     

     

     

    Monday, September 8, 2008 12:42 AM
  •  

    For some time now the progress bar states that it is adding an action for an icon file. A very small file.

     

    Many minutes follow - no change.

     

    The only thread running in synctoy uses 4% CPU, 96% of the system is idle. It's call stack:

     


    Thread Start Address:                                                         
    Symbol Name:                                         Line Number:           PC:
    mscorwks ! ClrCreateManagedInstance() + 0x8aa4       ------            79F959E8
                                                                                  
    Thread Stack::                                                                
    Symbol:                                              Line Number:           PCTongue Tiedtack Frame:
    ntdll ! _KiFastSystemCallRet@0() + 0x0               ------            7C90E4F4533E864
    ntdll ! _ZwWriteFile@36() + 0xc                      ------            7C90DF6C533E868
    KERNEL32 ! _WriteFile@20() + 0xf7                    ------            7C810E86533E8C8
    msfdbse ! InitSerialization() + 0x23222              ------            39842F20533E8F0
    msfdbse ! InitSerialization() + 0xff3b               ------            3982FC39533E914
    msfdbse ! InitSerialization() + 0x8e0f               ------            39828B0D533E934
    msfdbse ! InitSerialization() + 0xabb0               ------            3982A8AE533E96C
    msfdbse ! InitSerialization() + 0xe065               ------            3982DD63533E9A4
    msfdbse ! InitSerialization() + 0xe2b8               ------            3982DFB6533E9D4
    msfdbse + 69CF                                       ------            398069CF533E9F0
    msfdbse ! DllGetClassObject() + 0x16e1               ------            3981B292533EA84
    msfdbse ! InitSerialization() + 0x4502               ------            39824200533EAB8
    msfdbse ! SqlCePurgeTrackingGenerations() + 0x423a   ------            39817CBD533EAF8
    msfdb ! DllGetClassObject() + 0x108af                ------            3901D281533EB14
    msfdb ! DllGetClassObject() + 0x10e73                ------            3901D845533EB88
    msfdb ! DllGetClassObject() + 0x11be7                ------            3901E5B9533EBBC
    Metastore ! DllGetClassObject() + 0x60df             ------            1900DB31533EBE8
    Metastore ! DllGetClassObject() + 0x7a8b             ------            1900F4DD533EC2C
    Metastore ! DllGetClassObject() + 0x14dcd            ------            1901C81F533EC80
    Metastore ! DllGetClassObject() + 0xaa89             ------            190124DB533EC98
    FileSyncProvider ! DllGetClassObject() + 0xa8e8      ------            2900F157533ECB4
    FileSyncProvider ! DllGetClassObject() + 0xf9eb      ------            2901425A533F340
    FileSyncProvider ! DllGetClassObject() + 0x27ac      ------            2900701B533F368
    Synchronization ! DllGetClassObject() + 0x83c4       ------             90106B6533F38C
    Synchronization ! DllGetClassObject() + 0x9e22       ------             9012114533F3C8
    Synchronization ! DllGetClassObject() + 0xa002       ------             90122F4533F3E0
    Synchronization ! DllGetClassObject() + 0xa32b       ------             901261D533F400
    Synchronization ! DllGetClassObject() + 0xa9dc       ------             9012CCE533F420
    Synchronization ! DllGetClassObject() + 0xb744       ------             9013A36533F440
    Synchronization ! DllGetClassObject() + 0x86d2       ------             90109C4533F45C
    Synchronization ! DllGetClassObject() + 0xa5bb       ------             90128AD533F490
    Synchronization ! DllGetClassObject() + 0xb1b9       ------             90134AB533F4CC
    Synchronization ! DllGetClassObject() + 0xb33d       ------             901362F533F500
    FileSyncProvider ! DllGetClassObject() + 0x9d3a      ------            2900E5A9533F53C
    FileSyncProvider ! DllGetClassObject() + 0x567e      ------            29009EED533F584
    Synchronization ! DllGetClassObject() + 0x14fb2      ------             901D2A4533F5E0
    Synchronization ! DllGetClassObject() + 0x1557a      ------             901D86C533F61C
    Synchronization ! DllGetClassObject() + 0x1584c      ------             901DB3E533F634
    mscorwks ! DllUnregisterServerInternal() + 0x2662    ------            79E7575E533F754
    mscorwks ! DllUnregisterServerInternal() + 0x28d2    ------            79E759CE79E7575E

     

    Monday, September 8, 2008 12:51 AM
  • I am getting a sort of perverse interest in this.

     

    For the last few minutes nothing appears to be happening except one of Synctoy's thread is

    using 8-12% of the CPU.

     

    Looking closely at it, I see that it is reading two of the synctoy .dat files obviously comparing

    two folders via these files. The file position pointers are moving around like random number generators

    varying at every screen sample update from 0 to 40,000,000. This goes on for many minutes.

    Monday, September 8, 2008 1:16 AM
  • Another thing I noticed: Synctoy doesn't use very much memory. It uses about 16 MG of physical RAM.

    I have over 2 GB of free ram.

     

    It keeps reading these 40 MB .dat files randomly from disk. They are very heavily fragmented so it is

    travelling all through the disk for every read.

     

    Why not load them into memory? They will all fit - the whole SyncToy applications folder of .dat files takes up

    765 MB. That would boost the read/write throughput at least a thousandfold.

     

    I do have SATA drives capable of 100 MB/s but memory is so much faster...

     

     

     

     

    Monday, September 8, 2008 1:29 AM
  • Taking a chance, I started the PerfectDisk defragmenter running on the E partition where the .dat files are located.

     

    They were very badly fragmented. And I'm being kind with the adjectives.

     

    PD ran for a short time and almost immediately Synctoy completed.

     

    It reported that about 2,000 operations were required to do the sync.

     

    Here's the last lines of the log file:


    SYNC: 09/07/2008 14:58:40:968: Started scanning directory : X
    SYNC: 09/07/2008 14:58:40:984: Started scanning directory : Y

    SYNC: 09/07/2008 15:05:00:812: Stopped scanning directory : X
    SYNC: 09/07/2008 17:38:30:828: Stopped scanning directory : Y

    SYNC: 09/07/2008 18:34:47:609: Preview of Z in time 03:36:06:203.
    SyncToy action was 'Synchronize'
    Found 86 actions to perform.
    Found 136,303 files that did not require action.
    Analyzed 10.5 files per second.
    Avoided copying 43,869,282,382 bytes in 136,303 files.
    Saved approximately 00:22:18:00 by not copying any files.

     

    In other words, it took 3.5 hours to avoid doing what may have taken 22 minutes to perform via direct copy if

    I read this correctly.

     

    I will now perform an actual run, not a preview,  and see if the defragmented files make any difference.

     

     

     

     

     

     

    Monday, September 8, 2008 1:48 AM
  •  

    It has been running a while and seems stuck.It rapidly did 375 of the 2,000 operations and then

    halted at 375 for some time now.

     

    Looking at the active thread, it is once again going madly through the file positions of

    two .dat files. It looks like it is repeating the same thing it did for preview, only now the files

    are defragmented and the CPU is much higher - 45%.

     

    Still, I can't help but think how much better this would be if the database were in memory instead

    of on a hard drive.

     

    Monday, September 8, 2008 2:04 AM
  •  

    I can't believe what I am seeing.

     

    One of the files that Synctoy is using went from 1 fragment (after defragmentation)

    and now it is fragmented into 660 parts!. No files have changed, I just switched from preview to run.

     

    Why does it have to rebuild these blasted database again? And why rebuild it in such small chunks? And

    if it must use small chunks why can't it allocate a big chunk and use small parts of that in a contiguous disk

    area?

     

    It looks like this is going to run all night...

     

     

     

    Monday, September 8, 2008 2:13 AM