Ignore file like .gitignore

[verglor]

Maybe once ignore files are parsed they could be cached until changed or full scan ?

What about if during full scan all ignore files are parsed and converted to job exclusions but saved separately in sqlite db ? Now we would have for the job two sets of exclusions:

1. generated exclusions (from ignore files) unmodifiable in UI
2. normal (current) job exclusions modifiable by user in UI

Generated exclusions will be applied before normal exclusions and will be purged and regenerated during each full scan. They should be also regenerated when the ignore file is modified (or created/moved/deleted) - probably the path of ignore file (relative to job’s folder) will have to be saved for each generated exclusion to be able to evict only relevant exclusions.

[lajawi]

I’m awfully sorry to revive this topic after 6 six years, but as far as I know, this hasn’t really made it into Duplicati yet?

@verglor

I think that .gitignore ignores only files since there is not really a concept of folders in git. In that case there should not be a problem with ignored folders since only files are ignored.

As far as I’m aware, Git’s .gitgnore files can in fact ignore folders and subfolders. Any entries ending with a slash (/) are treated as such. I did not find anything explicitly stating this fact, but I know of and have used this formatting myself, and it seems to work wonderfully with Git.
https://git-scm.com/docs/gitignore#_pattern_format

@JonMikelV

OK - are we talking something like this?

• if .duplicati-ignore exists, ignore all files AND subfolders
• If .duplicati-ignore-files exists, ignore all the files in the folder but continue process subfolders
• if .duplicati-ignore-folder exists, process all the files in the folder, but ignore subfolders

To me, a custom ignore file wouldn’t make much sense. While the .gitignore file clearly has Git in its name, it can still apply for other programs like Duplicati. Reusing this naming is especially useful if you were to backup projects tracked by Git that have extra installation folders that are not tracked by Git because of their size and the ability to regenerate them! So backing those folders up would be unnecessary, because, as previously stated, they can be regenerated.

Think for example about a Node.js project. You install packages through the npm install command, which makes an entry in the package.json and package-lock.json files, and installes the package itself in the node-modules folder. A .gitignore file for such a project would exclude the node-modules/ directory, because all those packages can be reinstalled because of the aforementioned package files.

@molecular_eskimo

the .gitignore file never specifies files/directories to include

I hate to be a nitpicker, but there it is possible to ignore all files and folders, and then use the .gitignore file as an include file.

• An optional prefix “!” which negates the pattern; any matching file excluded by a previous pattern will become included again.
  Git - gitignore Documentation

By ignoring all files and folders first (*), and then prefixing all files and folders you do want to include with a exclamation mark (!), you basically turn the “ignore”-file into an “include”-file.

@JonMikelV

I think a goofier example would be what happens when a user specifically says to include C:\Users\myUser\Downloads\ but then puts creates C:\Users\myuser\.duplicatignore that says to IGNORE the Downloads folder.

In my opinion, anything that the user explicitly does allow through Duplicati’s UI, should be backed up no matter any ignore-file. It should still display a warning though, to warn the user of this conflict.

[ts678]

@lajawi

as far as I know, this hasn’t really made it into Duplicati yet?

Add support for a `.duplicati-ignore` file

is still open, but it seems you found it since, so this is for others.