Folders reappearing on receive end when remote device is shutdown

[terry]

Not sure if this is a bug, by design or version specific.

So last few days I have been working on a clients Windows PC and now that it’s tidied up, I want to sync it’s contents to me. Long story short I have been fighting with ignore patterns to block the Windows folders / files and send the rest to me and think i’m close, however some folders such as i386 / config.msi just keeps coming back.

My issue here isn’t so much with the patterns, but it seems the receive only St will keep repopulating the destination folder, even when the send only end is shutdown…

send only end

receive only end

I then delete the two highlighted

then a few minutes back the folders are coming back

receive end folder

I have tried reverting, it…

and the config.msi / i386 folders are now all back…

So it feels like the receive end is still building the folder structure (not the contents / files) based on the contents within it’s database despite the remote end being paused and locally is showing as disconnected.

I have been trying different ignore patterns on i386 to try and figure this out, this is the current version (and it was /i386 at one point)…

and suspect that some i386 patterns are wrong (been experimenting), but I have got to a point where I can’t figure out how to stop i386 / Config.Msi reappearing, and just maybe, i’m looking at the wrong end. eg, it’s the receiving end thats doing it.

There’s other folders doing the same thing, such as default and public in the users profile folder, but the above is easier to see

There’s no ignore file on the receiving end

In my mind, the receiving end should only create folders when instructed to be the sending end, not what it’s database tells it to.

all 1.6.0 -rc5

[calmh (Jakob Borg)]

@terry

So it feels like the receive end is still building the folder structure (not the contents / files) based on the contents within it’s database despite the remote end being paused and locally is showing as disconnected.

Sure. For directories it can do this because it doesn’t need anything from the remote side, as all the information needed to create a directory is in the database. For files that’s usually not the case, and I don’t think it’ll try even if all required blocks to build the file are theoretically available locally.

[terry]

Is there a way to revert this folder only in order to clear out that information? I’m assuming it’s case of delete the folder and re add?

[calmh (Jakob Borg)]

“Revert” has a specific meaning for receive only folder: “make the contents here the same as out there in the cluster”.

If you want to forget all contents and clear the database, then yes, remove the folder, remove the directory structure from disk, re-add it.

But presumably things are being created because they are announced from the other side. So once you connect to that other device they will be created again.

[terry]

I shall remove / add the receive folder and update the send end ignore pattern and report back the results.

Cheers

[terry]

No joy

Deleted the folder on the receive end then updated the ignore on the remote end to

which should ignore these folders but it’s come back

along with the contents

which suggests that the sending end pattern must be wrong? But other folders are being correctly ignored.

[imsodin (Simon)]

Handling a moving target is always difficult, because any change you make on the fs might take a long time to get scanned and cause various other effects. And your screenshots show that it’s clearly a lot that’s going on (tons of out of sync and failed items, tmp files lying around, …). If a sync doesn’t do what you want, pause the folder as a first step.

Few questions: What is shown on the send-only side (screenshot)? Did you make sure a scan happened after changing ignore patterns on the send-only side before connecting the removed-and-readded receive-only folder again?

[terry]

I had been pausing both ends and also the devices as often I wasn’t able to delete the receiving ends folder. I literally have been on this for a day before posting and read upteen threads on patterns and it was only in the last few hours that noticed the folders coming back regardless of the state of the sending end.

What I have done (probably wrongly) is deleted the index on the send end in case there was anything in there that wasn’t taking the ignore into consideration and just chatting to the send end with wrong data. eg.,

hello receiving end

here’s what I know currently of the folders within my database (with wrong folders)

I shall now do a scan and see whats changed.

hello sending end

thanks for your database, can I have files for i386 etc

bloody end users shutting me down again, catch ya laterz

At the moment the index deletion seems to be solving the issue as the folders have not come back (yet), but i’m only up to 10% (sending end scan)

[terry]

@imsodin

Did you make sure a scan happened after changing ignore patterns on the send-only side before connecting the removed-and-readded receive-only folder again?

When I made a change to the ignore patterns St then did a scan automatically.

initially I tried Tomasz suggestion found in a thread

However it didn’t follow the subfolders that I wanted so blew that ‘ignore’ away and went with ignoring system folders rather than trying to only include the ones I wanted.

[terry]

It’s looking more successful now. Just removing the receiving end folder and readding it didn’t take the issue away, but I had to remove the receive folder, delete the sending index, start the send end, add the receive end folder. Essentially starting from scratch.

It was as if the sending end sent the full folder list to the blank receive folder db as soon as they did their handshake.