Puller: final: The data present in the reparse point buffer is invalid

I’m having high memory usage problems with SynchTrayzor and was told to report some issues with Syncthing here. (https://github.com/canton7/SyncTrayzor/issues/141)

I’m running multiple servers and noticed that this entry shows up some of them: [N5G5J] 04:19:23 INFO: Puller: final: The data present in the reparse point buffer is invalid.

This seems to show up very often on those servers, as in 20+ times per second. I think it might be related to the read speed of the drives on those servers.

One of them has a Intel 750 PCIe NVMe SSD with ~2GBps throughput. The other one has a raid 1 array of Samsung 850 PRO ssd’s which should theoretically have a read speed of +1GBps.

This sounds like some deep Windows voodoo. It’s over my head.

Do you use some fancy windows deduplicated filesystem? Also if you enable STTRACE=model env var before running sycthing, and then get us the line number where it happends, I could lool into it.

Yes I do use the de duplication system build into Windows Server 2012 R2. (I do on the other servers as well, which don’t have this problem)

How do I enable the env var? Do you mean I should enable it as an environmental variable in Windows? If so should it be a user or system variable? Should the name be STTRACE and value model?

Google suggests issues with file resource manager blocking files of certain extensions being created on some volumes. Google around for the error for possible remedy, because syncthing does not use junctions or reparse points (apart from symlinks but they should not be validated) so this error makes no sense.

Also, try disabling symlinks in advanced options.

You can enable the var in the prompt before launching syncthing from the prompt.

To set environmental vars, go to Settings -> Syncthing, expand the ‘Advanced’ section, and put STTRACE=model in the “Environmental variables” box, hit save, then restart Syncthing when prompted.

He hasn’t posted the full log here, but there’s possibly a secondary issue: the message from the puller has severity INFO, but starts with ‘fatal’. The failures do not cause the puller to be paused either, leading to massive log files and a struggling GC on my end. Might this particular failure point be falling through some gaps?

If I remember correctly, the “final” (not fatal?) prefix is an error that occurs at the last stage of fixing up a file, i.e. setting the mtime and renaming. But I don’t have the code in front of me.

How do I disable symlinks? I don’t see that option under advanced.

Actions -> Advanced -> Options -> symlinksEnabled

It appears I can’t read… Anyway, don’t most other puller errors result in a pause at some point?

Okay, I’ll try that.

In the mean time here is a log with the debuging env enabled. (the synch had just started, so no memory issues yet. But I thought it might still be useful.)

    [FWFDC] 2015/09/17 20:08:07.866482 rwfolder.go:1037: DEBUG: rwFolder/Games@0xc08b54b7a0 need file css33\css\cstrike\materials\de_dust\sitebwall02.vtf; copy 1, reused 0
[FWFDC] 2015/09/17 20:08:07.868483 rwfolder.go:1343: INFO: Puller: final: The data present in the reparse point buffer is invalid.
[FWFDC] 2015/09/17 20:08:07.868483 progressemitter.go:129: DEBUG: progress emitter: deregistering Games css33\css\cstrike\materials\cs_havana\fraggrenade.vtf
[FWFDC] 2015/09/17 20:08:07.869478 progressemitter.go:116: DEBUG: progress emitter: registering Games css33\css\cstrike\materials\de_dust\sitebwall02.vtf
[FWFDC] 2015/09/17 20:08:07.875483 rwfolder.go:1333: DEBUG: rwFolder/Games@0xc08b54b7a0 closing arma3\kart\addons\soft_f_kart.ebo
[FWFDC] 2015/09/17 20:08:07.875483 rwfolder.go:1037: DEBUG: rwFolder/Games@0xc08b54b7a0 need file css33\hl2\sound\physics\wood\wood_plank_break2.wav; copy 1, reused 0
[FWFDC] 2015/09/17 20:08:07.875483 sharedpullerstate.go:181: DEBUG: sharedPullerState Games css33\css\cstrike\materials\de_dust\sitebwall02.vtf copyNeeded -> 0
[FWFDC] 2015/09/17 20:08:07.877483 rwfolder.go:1343: INFO: Puller: final: The data present in the reparse point buffer is invalid.
[FWFDC] 2015/09/17 20:08:07.877483 progressemitter.go:129: DEBUG: progress emitter: deregistering Games arma3\kart\addons\soft_f_kart.ebo
[FWFDC] 2015/09/17 20:08:07.877483 progressemitter.go:116: DEBUG: progress emitter: registering Games css33\hl2\sound\physics\wood\wood_plank_break2.wav
[FWFDC] 2015/09/17 20:08:07.877483 sharedpullerstate.go:181: DEBUG: sharedPullerState Games css33\hl2\sound\physics\wood\wood_plank_break2.wav copyNeeded -> 0
[FWFDC] 2015/09/17 20:08:07.897484 rwfolder.go:1037: DEBUG: rwFolder/Games@0xc08b54b7a0 need file css33\hl2\sound\ambient\levels\canals\waterleak_loop1.wav; copy 1, reused 0
[FWFDC] 2015/09/17 20:08:07.897484 rwfolder.go:1333: DEBUG: rwFolder/Games@0xc08b54b7a0 closing css33\css\cstrike\materials\de_dust\sitebwall02.vtf
[FWFDC] 2015/09/17 20:08:07.899484 rwfolder.go:1343: INFO: Puller: final: The data present in the reparse point buffer is invalid.
[FWFDC] 2015/09/17 20:08:07.899484 progressemitter.go:129: DEBUG: progress emitter: deregistering Games css33\css\cstrike\materials\de_dust\sitebwall02.vtf
[FWFDC] 2015/09/17 20:08:07.900484 progressemitter.go:116: DEBUG: progress emitter: registering Games css33\hl2\sound\ambient\levels\canals\waterleak_loop1.wav
[FWFDC] 2015/09/17 20:08:07.900484 sharedpullerstate.go:181: DEBUG: sharedPullerState Games css33\hl2\sound\ambient\levels\canals\waterleak_loop1.wav copyNeeded -> 0
[FWFDC] 2015/09/17 20:08:07.900484 rwfolder.go:1037: DEBUG: rwFolder/Games@0xc08b54b7a0 need file css33\css\cstrike\materials\cs_assault\assault_metalcrate001c_red.vtf; copy 1, reused 0
[FWFDC] 2015/09/17 20:08:07.900484 rwfolder.go:1333: DEBUG: rwFolder/Games@0xc08b54b7a0 closing css33\hl2\sound\physics\wood\wood_plank_break2.wav
[FWFDC] 2015/09/17 20:08:07.902484 rwfolder.go:1343: INFO: Puller: final: The data present in the reparse point buffer is invalid.
[FWFDC] 2015/09/17 20:08:07.902484 progressemitter.go:129: DEBUG: progress emitter: deregistering Games css33\hl2\sound\physics\wood\wood_plank_break2.wav
[FWFDC] 2015/09/17 20:08:07.902484 progressemitter.go:116: DEBUG: progress emitter: registering Games css33\css\cstrike\materials\cs_assault\assault_metalcrate001c_red.vtf
[FWFDC] 2015/09/17 20:08:07.902484 sharedpullerstate.go:181: DEBUG: sharedPullerState Games css33\css\cstrike\materials\cs_assault\assault_metalcrate001c_red.vtf copyNeeded -> 0
[FWFDC] 2015/09/17 20:08:07.903481 rwfolder.go:1037: DEBUG: rwFolder/Games@0xc08b54b7a0 need file CSGO2\directx_installer\JUN2007_d3dx9_34_x86.cab; copy 1, reused 0
[FWFDC] 2015/09/17 20:08:07.904485 rwfolder.go:1333: DEBUG: rwFolder/Games@0xc08b54b7a0 closing css33\hl2\sound\ambient\levels\canals\waterleak_loop1.wav
[FWFDC] 2015/09/17 20:08:07.906485 rwfolder.go:1343: INFO: Puller: final: The data present in the reparse point buffer is invalid.
[FWFDC] 2015/09/17 20:08:07.906485 progressemitter.go:129: DEBUG: progress emitter: deregistering Games css33\hl2\sound\ambient\levels\canals\waterleak_loop1.wav

AFAIK yes, we should retry that a few times and then chill for a minute. But if this is a systematic error, and we have thousands of files to pull, that’s thousands of log messages repeated a few times (plus a bunch of associated events) before we pause.

Apparently Clippy the evil Microsoft Word AI :stuck_out_tongue: (forum bot?) has temporarily removed my previous reply with a log before I disabled sym link, but after enabling the debuging env parameter.

Since I disabled sym link I get entries like:

[FWFDC] 2015/09/17 20:20:03.962503 model.go:1911: DEBUG: dropping update for unsupported symlink File{Name:"css33\\css\\cstrike\\sound\\bot\\they_wont_get_away.wav", Flags:0300666, Modified:0, Version:[{2968636072897108092 1} {3281489358145580549 1} {8020300210084024329 1} {9721796588774062338 4}], Size:0, Blocks:[Block{0/0/e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855}]}
[FWFDC] 2015/09/17 20:20:03.962503 model.go:1936: INFO: Unsupported symlink css33\css\cstrike\sound\bot\this_is_my_house.wav in folder Games

I suppose this is to be expected, since I turned off symlinks?

Yes. Although those files don’t sound like they should be symlinks, so I’m guessing something went wrong earlier in the process. Probably related to the funky business that Windows deduplication seems to be.

Yeah deduped files are recognized as symlinks, that’s a Go bug:

1 Like

AFAIK the de duplication system works below the file system level. I don’t know how low level syncthing/synchtrayzor work to know if it affects anything.

Right, so in effect we don’t fully support running on deduplicated volumes. I wonder if this works if symlinks are disabled before the initial scan on that volume - either by config, or because you are running as a user without the relevant permissions?

It appears that disabling symlinks in the advanced options resolved the problem. Memory usage looks normal. I’ll report back if I notice memory problems again.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.