Client: Per-directory sync exclusions

[eigengrau]

It would be a useful enhancement if sync exclusions could not only be specified globally, but also per directory. E.g., I often would like to ignore the intermediate output of my LaTeX-projects (*.out, *.run.xml, etc.). I cannot ignore these glob patterns globally, since they are also used by files which I would like to sync.

A possible solution would be to allow local .sync-exclude.lst files within folders. These exclusion lists would apply only to paths within and below the directory within which they are placed.

An alternative approach would keep the global exclusion list, but allow ** in glob patterns to match across subdirs recursively (same as the Bash “globstar”). E.g., this would allow specifying a pattern latex/**/*.out to match .out files only if they are somewhere beneath latex/.

[oruchreis]

+1 for this enhancement but allowing local exclude files within folders would be more useful as I said in my duplicate suggestion #4068

[arifemre]

I'm waiting this feature, too

[Awpteamoose]

Pretty please, I thought the current ignore settings were like that and got burned after I confifgured the server and everything.

[dragotin]

Have you checked exclude patterns like

latex/*/*.out

That works. See d89edc35d2af3686370cde6a67613b7208749808

[qw3ry]

I really like this idea and was just about to submit the same ticket when I luckily found this one.

I like to point out that this is not only about LaTeX output. For me this feature would mean

• no more separate handling of ignore lists for each client (that is on each machine)
• a central option to exclude files from sync for shared projects (like repositories used by multiple OC users)

Furthermore I would recommend using the syntax from .gitignore-files (or an extension), as it is easy and those files are quite common (and therefore, their syntax). Furthermore one could be symlinked to another instead of duplicating the file (Of course the client could allow the user using .gitignore-files itself).

[jvcdk]

+1 from me as well.

Any news from ownCloud team... is this something anyone is working on? Would a patch be accepted if I implemented it?

~Jørn

[hodyroff]

Please comment on https://github.com/owncloud/client/issues/1558#issuecomment-170334605
Generally yes, this could be interesting on a per folder bases. Challenge is how to make a user experience which works and can be understood or stays away from the not so technical "normal" office user of ownCloud.

[qw3ry]

@hodyroff Re user experience:

• for "staying away from the average user": using a hidden file to configure it (like .gitignore) will keep this setting away from non-technical users.
• for "nice UX": One could edit the global ignores with a syntax using wildcards, e.g. /some/path/to/a/folder/**/*.html. OTOH I'd prefer something like .gitignore because you can easily copy'n'paste these between different folders.

I notice this is basically what @eigengrau suggested. Are there any problems with this approach?

[cpesoft]

+1 for this feature

[sryze]

This would be useful for me as well, e.g. for excluding node_modules and build outputs (something like .owncloudignore)

[ashthespy]

I've been scouring the docs, but haven't found an elegant solution yet. I just realised I've been syncing couple of GB of Rust ./target/release/.fingerprint files.

A lot of other repos also sync all my build artefacts across and I'd like to avoid hardcoding paths on each of my machines, and check in a .owncloudignore or something similar to each repo to avoid this in the future.

[maxfrei750]

@TheOneRing Thanks for pointing me to this issue.

This seems to be a highly requested feature, which unfortunately has not been implemented in the past 7 years. Maybe it would be helpful, if one of the core developers could shed some light onto why this feature is not being addressed and what the community could do to help with the implementation. Thanks.

[maxfrei750]

@TheOneRing Would you mind helping with this issue? Either directly or by pinging the most suitable developer(s)?

[maxfrei750]

@ogoffart @dragotin @michaelstingl Since @TheOneRing is apparently unavailable for this issue, maybe one of you can help?

Is this feature wanted by the Owncloud team? If not, when why not? If yes, then what could the community do to speed up the implementation and what would reasonable first steps look like? Thanks!