Create a dir in a shared folder, let’s call it pattern. Populate it with dummy files if you want.
Use this list of exclusions:
!pattern
*
let sync ok
change the exclusions list to
//!pattern
*
then remove the dir (rm -rf pattern)
then change you mind and decide you need pattern back to local: so set exclusions list back to
!pattern
*
This will end in pattern is deleted at remote devices. I met this yesterday in a real life tree : as soon as I set the exclusions list back as just above, I saw the GUI showing download from remote for a while, but nothing was on local side, and no more on remote. The strange also is that nothing was in local .stversions after that. A chance, the dir and content was on remote .stversions (simplified versioning on remote with filename~timestamp made me sure only me was involved in the process of deletion)
I thing I already read a thread here or a github bug report for this, so this is just a reminder for .stignore users.
This is expected. You might think that since the delete happened when the ignore patterns were in place it would not propagate. Nonetheless we did have those files, and announce them prior to them being ignored. Then they were ignored for a while. Now they’re deleted and not ignored, so that gets propagated. The alternative would be to still announce that we have the files, which would result in other problems.
Intended vs expected… I’d rather like not this is intended. Although, with Jakob explanation I think I understand why it’s an expected behaviour. But maybe we could have another point of view which lead to other problems if it doesn’t shake the whole philosophy of ST: yes we (local) did have the files and announced them (incidentally, there is some fun knowing we put them in the folder ). Then we ignore them for a while. Wouldn’t it be at this very moment, because ignoring is a local (even private I’d say) and a corner case process in the main ST behaviour, that you Devs would decide how you want to deal with the trap I met. The ignoring process (we) being local is a chance because it sees what happens on local side and can decide what do without having to tell anything to others. E.g decide we could want to ignore anything that happens to a local ignored file (change or deletion), I mean give the precedence to a file’s existence(positive)/version already in the folder’s global DB at the moment we decide to unignore… or deal that with a conflict. Would an ignored file be added locally and non-existent in folder’s global DB, it would be synced to the cluster at unignore time.
Maybe the local DB would be purged of ignored files at ignore time?
In fact I don’t know how ignore process works behind the scene. Does it stores and/or keeps any files (hashes…) informations respectless they are ignored or not?
If the behaviour is really intended, we either should have a warning in .stignore header and GUI about it, or ignore feature would be moved to Advanced, or simply removed.
That should be already the case: if any remote has the file, and you unignore the locally deleted one, the remote will conflict with the local one and thus not get deleted.
I am quite sure we do reset the version on unignore, resulting in what i described. However you might hit an edge case that is due to “static” version vectors (issue exists about that): If you only ever created that file before ignoring, no changes whatsoever, resetting doesnt have any effect as the new version gets the same vector id.
Could you please direct me to the github issue and/or forum thread so that I read more and understand this vector concept whose I hear the name for the first time. Hopefully I’ll find to workaround my way to use ST so that I’m not affected by the issue.
). Then we ignore them for a while. Wouldn’t it be at this very moment, because ignoring is a local (even private I’d say) and a corner case process in the main ST behaviour, that you Devs would decide how you want to deal with the trap I met. The ignoring process (we) being local is a chance because it sees what happens on local side and can decide what do without having to tell anything to others. E.g decide we could want to ignore anything that happens to a local ignored file (change or deletion), I mean give the precedence to a file’s existence(positive)/version already in the folder’s global DB at the moment we decide to unignore… or deal that with a conflict. Would an ignored file be added locally and non-existent in folder’s global DB, it would be synced to the cluster at unignore time.