.syncignore issue with subfolders of windows user profile

[Tommmii]

Hi,

 

I've been reading up on several threads / FAQs re the .syncignore file created in the root of a sync-folder.

Running 2 windows7 machines, btsync 1.1.82

 

For this sync, the root is c:\Users\Christiane

Both machines have just the one line in their .syncignore :

AppData

I can see syncing going on for folders 

AppData\Roaming\Microsoft\Windows\CookiesAppData\Roaming\BitTorrent Sync

Why?

[Guest]

Hi,

 

I've been reading up on several threads / FAQs re the .syncignore file created in the root of a sync-folder.

Running 2 windows7 machines, btsync 1.1.82

 

For this sync, the root is c:\Users\Christiane

Both machines have just the one line in their .syncignore :

AppData

I can see syncing going on for folders 

AppData\Roaming\Microsoft\Windows\CookiesAppData\Roaming\BitTorrent Sync

Why?

Hi, Tommii

You should add to .SyncIgnor two rules: folder2 and  folder2/* to ignore a subfolder. 

[Tommmii]

hi o-awesome-o, thanks for your suggestion.

Unfortunately changing the .Syncignore to

AppDataAppData/*

doesn't change anything.

Please also take note that, knowing windows, the AppData folder has many subfolders.

BTsync seems to be ignoring all folders as instructed, except for the 2 folders mentioned earlier.

 

Also, in between each modification to the .Syncignore file, I'm removing the shared Sync folder at both sides, and I empty the contents of the folder on the destination machine.

I then modify the .Syncignore and restart BTsync.

[vadimt]

Please add the following to your .SyncIgnore file:

AppData
AppData\*

Your OS is Windows and you should use "\" in the path.

Thanks!

[Christian_K]

Actually I have exactly the same issue described in this thread and in other threads.

 

In my environment all settings in .SyncIgnore are completely ignored.

 

I did various tests with a sample folder with different .SyncIgnore entries:

• path separators / and \
• with and without * and \* at the line end.
• with Bittorrent Sync restart
• without having the .SyncIgnore file opened in my editor

No solution yet.

 

I am doing Windows 7 Ultimate 64 bit --> read-only sync --> Linux (Synology NAS).

 

Might be a problem of the unidirectional sync (read-only sync).

 

Looking forward for a solution.

 

Thx in advance.

[GreatMarko]

In my environment all settings in .SyncIgnore are completely ignored.

Remember that any changes you make to .SyncIgnore won't take affect until you restart Sync, and that your .SyncIgnore files need to be identical for the folder you're syncing on all your devices

[Tommmii]

as vadim has said : 

AppData

AppData\*

Your OS is Windows and you should use "\" in the path.

 

That's working for me, I have windows machines on both sides of the sync... what if one side of the sync is Win and the other side is a Linux machine ? Should the paths in .syncignore be different ?

[Christian_K]

... well, as I said it is completely ignored

 

Remember that any changes you make to .SyncIgnore won't take affect until you restart Sync, and that your .SyncIgnore files need to be identical for the folder you're syncing on all your devices

 

yes, I did a restart that as I said. The settings are .SyncIgnore is still completely ignored. Thanks for your response anyway.

[Christian_K]

 

as vadim has said : 

AppData

AppData\*

Your OS is Windows and you should use "\" in the path.

 

That's working for me, I have windows machines on both sides of the sync... what if one side of the sync is Win and the other side is a Linux machine ? Should the paths in .syncignore be different ?

 

Not working for me. Do you have a unidirectional sync also, i.e. are you using the read-only key?

[bmattis]

Not working for me. Do you have a unidirectional sync also, i.e. are you using the read-only key?

 

Not working for me either. It keeps on syncing stuff in the AppData directory.

 

This is on a WinXP PC which backs up a read-only sync from a WinVista PC.

 

Btw, do the .syncignore *files* need to be identical, or is it the parsed text data that needs to be identical? In other words, does a linebreak or a whitespace in one of the files break the validity?

And is there a chance to see if two folders have mismatching .syncignore files, via a warning message or log entry or something? I guess every user would always want to get alerted about this immediately.

[Tommmii]

Not working for me. Do you have a unidirectional sync also, i.e. are you using the read-only key?

 

Yes, I am also using the read-only key for this case.

 

 

Btw, do the .syncignore *files* need to be identical, or is it the parsed text data that needs to be identical? In other words, does a linebreak or a whitespace in one of the files break the validity?

And is there a chance to see if two folders have mismatching .syncignore files, via a warning message or log entry or something? I guess every user would always want to get alerted about this immediately.

 

When I was setting this up, I usually copied the entire .syncignore file from one machine to the others. In some cases I copied the contents of the file. Both ways would have preserved the file format (CRLF, etc).

I never use MS Notepad when editing, always used notepad++

[SubCog]

Hi,

 

I've been reading up on several threads / FAQs re the .syncignore file created in the root of a sync-folder.

Running 2 windows7 machines, btsync 1.1.82

 

For this sync, the root is c:\Users\Christiane

Both machines have just the one line in their .syncignore :

AppData

I can see syncing going on for folders 

AppData\Roaming\Microsoft\Windows\CookiesAppData\Roaming\BitTorrent Sync

Why?

I have exactly the same problem.  Despite my syncignore, it still attempts to sync these two folders.  Any solution yet?

[RomanZ]

@SubCog

I suggest you used correct path delimiter symbol. Please try re-adding the folder to sync (you may use the same secret) and when adding - make sure that syncignore already present in the folder. In this case BTSync wont even add ignored entries to the internal folder tree.

[Christian_K]

Well I gave it another try.

I was able to run tests doing a unidirectional sync from Windows 7 64bit > Mac

 

(I don't see any version information but BTSync has been downloaded today.)

 

1.) Excluding folders

 

Good news: I was able to fully exclude a folder:

a\

... fully excluded the folder named 'a' of my sync root directory.

Fully exclude means that the folder does not even appear on sync target. If you write

a

instead, i.e. without the backslash at the end of the line, then none of the files inside of the folder 'a' will be synced, not even the files inside of nested directories. But it is really strage that the entire (blank) directory structure below the folder 'a' (without any file) will be synced to the sync target.

 

So far so good. The important thing appears to be the backslash at the end of the line in case you want to exclude folders.

 

The bad news is that folder exculsion does not work with wildcards. If you write

*\target\

this does not mean, - in conjunction with code line no. 1 - that all target folders of the following structure will be fully excluded from the sync process:

<your root>+---1¦   +---src¦   +---target+---2¦   +---src¦   +---target+---3    +---src    +---target

If you are using wildcards, it appears to make no difference if you write

*\target\

or

*\target

or

*\target\*

The entire folder structure of 'target' and its nested folders will be synced without any files.

 

 

1.) Excluding files

A file named 'New Text Document.txt' inside of sync root directory could be ignored by just adding the full filename:

New Text Document.txt

This appears to prove that there are no issues with blanks.

 

... I did not do any further investigations yet

[bmattis]

The fabulous Bittorrent team would really need to make a clear and user-friendly GUI for file & folder selection. 

 

The current old-school .SyncIgnore text file solution is surely preferred by some computer boffins, but it is way too cryptic for the broad range of users, and - as this discussion thread shows - even the relatively nerdy of us have a hard time actually getting it right (or even understanding the exact results of what we try). In a sync/backup tool, every uncertainty is potentially dangerous.

 

A new GUI-based selection could still be combined with the old text file solution, rendering a new text file when setting has been changed in the GUI (and vice versa). This would also make it much clearer what the lines in the text file actually mean.

[RomanZ]

@Christian_K

There was a bug found with ignorelist recently - therefore the "*\target\" might not be ignored in your sample. We'll release a fix in upcoming build.

 

@bmattis

We'll make IgnoreList more friendly eventually. There was a number of voices raised about it in Feature Request forum.

[bmattis]

@bmattis

We'll make IgnoreList more friendly eventually. There was a number of voices raised about it in Feature Request forum.

 

Sounds great! :-)

 

Another aspect that I forgot to mention is the need of an indication of agreeing or disagreeing clients in regard to the IgnoreLists. As of now, you never know for sure if the IgnoreList is working or not since there is no indication that both sides have matching text files.