List of paths or files to ignore in every new torrent #11807

Author

Owner

@pdfrg commented on GitHub (Jan 18, 2024):

I am using the "Preferences > Downloads > Excluded file names" feature, which works great for individual files.
e.g. "*.exe" and "sample.*"

However, I cannot figure out how to get it to exclude entire subfolders.
e.g. "Featurettes" and "Extras"

I have tried things like
"*Extras*"
"Extras/*"
but these do not work.

Sometimes these folders contain gigabytes of data that I do not want. Am I missing something, or is this not possible currently? If it is not, I would love to have the ability, so that I don't have to go through every torrent and de-select each directory.

Thank you.

@pdfrg commented on GitHub (Jan 18, 2024): I am using the "Preferences > Downloads > Excluded file names" feature, which works great for individual files. e.g. "\*.exe" and "sample.*" However, I cannot figure out how to get it to exclude entire subfolders. e.g. "Featurettes" and "Extras" I have tried things like "\*Extras*" "Extras/*" but these do not work. Sometimes these folders contain gigabytes of data that I do not want. Am I missing something, or is this not possible currently? If it is not, I would love to have the ability, so that I don't have to go through every torrent and de-select each directory. Thank you.

deekerman commented

Author

Owner

@cheater commented on GitHub (Jan 18, 2024):

i don't really know, but i have a hunch that for every file that's in a torrent, libtorrent keeps the file name and the relative path where the file is stored in separate fields of a struct, and qbittorrent is only checking the file name field and not the relative path. so that's what needs to be fixed.

@cheater commented on GitHub (Jan 18, 2024): i don't really know, but i have a hunch that for every file that's in a torrent, libtorrent keeps the file name and the relative path where the file is stored in separate fields of a struct, and qbittorrent is only checking the file name field and not the relative path. so that's what needs to be fixed.

deekerman commented

Author

Owner

@glassez commented on GitHub (Jan 18, 2024):

libtorrent keeps the file name and the relative path where the file is stored in separate fields of a struct

It is incorrect.
But qBittorrent really apply it to filenames only:
github.com/qbittorrent/qBittorrent@00372dd559/src/base/bittorrent/sessionimpl.cpp (L2816)

@glassez commented on GitHub (Jan 18, 2024): > libtorrent keeps the file name and the relative path where the file is stored in separate fields of a struct It is incorrect. But qBittorrent really apply it to filenames only: https://github.com/qbittorrent/qBittorrent/blob/00372dd559dedd19e3bcb66db8e7d5faf597d4b2/src/base/bittorrent/sessionimpl.cpp#L2816

deekerman commented

Author

Owner

@cheater commented on GitHub (Jan 18, 2024):

hmm, looks like it isn't a hard fix

@cheater commented on GitHub (Jan 18, 2024): hmm, looks like it isn't a hard fix

deekerman commented

Author

Owner

@glassez commented on GitHub (Jan 18, 2024):

hmm, looks like it isn't a hard fix

Looks like it was done intentionally. I wonder why? (Maybe it was discussed, but I don't remember.)

@glassez commented on GitHub (Jan 18, 2024): > hmm, looks like it isn't a hard fix Looks like it was done intentionally. I wonder why? (Maybe it was discussed, but I don't remember.)

deekerman commented

Author

Owner

@cheater commented on GitHub (Jan 18, 2024):

it was committed by @thalieht - would you mind letting us know the reason it's like that? TY

@cheater commented on GitHub (Jan 18, 2024): it was committed by @thalieht - would you mind letting us know the reason it's like that? TY

deekerman commented

Author

Owner

@thalieht commented on GitHub (Jan 18, 2024):

it was committed by @thalieht - would you mind letting us know the reason it's like that? TY

@mxtsdev is the author of this feature. I just changed the indentation there.

@thalieht commented on GitHub (Jan 18, 2024): >it was committed by @thalieht - would you mind letting us know the reason it's like that? TY @mxtsdev is the author of this feature. I just changed the indentation there.

deekerman commented

Author

Owner

@cheater commented on GitHub (Jan 18, 2024):

right, sorry, thanks. @mxtsdev would you mind chiming in? thanks

@cheater commented on GitHub (Jan 18, 2024): right, sorry, thanks. @mxtsdev would you mind chiming in? thanks

deekerman commented

Author

Owner

@pdfrg commented on GitHub (Feb 1, 2024):

OK it has been 2 weeks. @mxtsdev are you available to comment? If not, who else to forward this to? Thanks.

@pdfrg commented on GitHub (Feb 1, 2024): OK it has been 2 weeks. @mxtsdev are you available to comment? If not, who else to forward this to? Thanks.

deekerman commented

Author

Owner

@cheater commented on GitHub (Feb 1, 2024):

mxtsdev has no activity since october. i suggest just disregarding this, it doesn't matter. if bugs start happening because if it we'll know soon enough.

@cheater commented on GitHub (Feb 1, 2024): mxtsdev has no activity since october. i suggest just disregarding this, it doesn't matter. if bugs start happening because if it we'll know soon enough.

deekerman commented

Author

Owner

@cheater commented on GitHub (Feb 1, 2024):

maybe it's because paths are different on unix vs windows, and they didn't want to deal with that during the matching.

@cheater commented on GitHub (Feb 1, 2024): maybe it's because paths are different on unix vs windows, and they didn't want to deal with that during the matching.

deekerman commented

Author

Owner

@pdfrg commented on GitHub (Feb 1, 2024):

Sorry, I don't follow. Did you already make a change that will allow to filter folders? If so, THANK YOU

@pdfrg commented on GitHub (Feb 1, 2024): Sorry, I don't follow. Did you already make a change that will allow to filter folders? If so, THANK YOU

deekerman commented

Author

Owner

@cheater commented on GitHub (Feb 1, 2024):

no, but the code as it is right now takes the complete path and strips it to just the name of the file, so that's what @glassez meant when he said it's "done on purpose". i was just speculating that this was the purpose.

@cheater commented on GitHub (Feb 1, 2024): no, but the code as it is right now takes the complete path and strips it to just the name of the file, so that's what @glassez meant when he said it's "done on purpose". i was just speculating that this was the purpose.

deekerman commented

Author

Owner

@8tm commented on GitHub (Mar 7, 2024):

I think after almost 2 months without response from author, we can change that :)

This task is now 3 years old 😃

@8tm commented on GitHub (Mar 7, 2024): I think after almost 2 months without response from author, we can change that :) This task is now 3 years old :smiley:

deekerman commented

Author

Owner

@pdfrg commented on GitHub (Mar 27, 2024):

Whether it was decided not to be able to exclude directories on purpose or not, I think it is a legitimate request. As mentioned, in many cases these contain gigabytes of files. This is a significant waste for those who do not have fiber internet or unlimited download quotas. I'd appreciate it very much if this would be considered/re-considered. Thanks.

@pdfrg commented on GitHub (Mar 27, 2024): Whether it was decided not to be able to exclude directories on purpose or not, I think it is a legitimate request. As mentioned, in many cases these contain gigabytes of files. This is a significant waste for those who do not have fiber internet or unlimited download quotas. I'd appreciate it very much if this would be considered/re-considered. Thanks.

deekerman commented

Author

Owner

@iansebryk commented on GitHub (May 1, 2024):

any word on whether or not we can filter folders yet? getting sick of having to retroactively delete clogged folders that shouldn't have been downloaded to begin with.

@iansebryk commented on GitHub (May 1, 2024): any word on whether or not we can filter folders yet? getting sick of having to retroactively delete clogged folders that shouldn't have been downloaded to begin with.

deekerman commented

Author

Owner

@glassez commented on GitHub (May 30, 2024):

Could you try #20902?

@glassez commented on GitHub (May 30, 2024): Could you try #20902?

deekerman commented