Start qBittorrent.
Add a torrent in a stopped state.
Go to the content tab and select/unselect items.
Files are created with a size of 0 bytes. This is exacerbated if file preallocation is enabled. MOTW is disabled.

Additional context

No response

Log(s) & preferences file(s)

n/a

Originally created by @stalkerok on GitHub (Nov 15, 2024). ### qBittorrent & operating system versions qBittorrent v5.0.1 (64-bit) Qt: 6.7.3 Libtorrent: 1.2.19.0 Boost: 1.86.0 OpenSSL: 3.4.0 zlib: 1.3.1 OS: W10 ### What is the problem? Files are created even if the download has not started. https://github.com/user-attachments/assets/563a4417-525e-4ce2-afe1-37d3ecab4306 https://github.com/user-attachments/assets/3ade2e1b-1238-40ec-8781-6360d5752b12 ### Steps to reproduce Start qBittorrent. Add a torrent in a stopped state. Go to the content tab and select/unselect items. Files are created with a size of 0 bytes. This is exacerbated if file preallocation is enabled. MOTW is disabled. ### Additional context _No response_ ### Log(s) & preferences file(s) n/a

deekerman added the

Libtorrent

label

2026-02-22 03:03:09 -05:00

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Nov 15, 2024):

This is a libtorrent issue for sure. Check if 2.0 has the same behavior.

@HanabishiRecca commented on GitHub (Nov 15, 2024): This is a libtorrent issue for sure. Check if 2.0 has the same behavior.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@stalkerok commented on GitHub (Nov 15, 2024):

The behavior is the same.

@stalkerok commented on GitHub (Nov 15, 2024): The behavior is the same.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@unregd commented on GitHub (Dec 2, 2024):

5.0.2
Win10pro

Qt: 6.7.3
Libtorrent: 1.2.19.0
Boost: 1.86.0
OpenSSL: 3.4.0
zlib: 1.3.1

"Do not start the download automatically" is turned on.
When a torrent containing 0 length files is added these dirs\files are created immediately without touching anything.
Preallocation on or off makes no difference.

@unregd commented on GitHub (Dec 2, 2024): 5.0.2 Win10pro Qt: 6.7.3 Libtorrent: 1.2.19.0 Boost: 1.86.0 OpenSSL: 3.4.0 zlib: 1.3.1 "Do not start the download automatically" is turned on. When a torrent containing 0 length files is added these dirs\files are created immediately without touching anything. Preallocation on or off makes no difference.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Dec 2, 2024):

When a torrent containing 0 length files is added these dirs\files are created immediately without touching anything.

This one is intentional.

@HanabishiRecca commented on GitHub (Dec 2, 2024): > When a torrent containing 0 length files is added these dirs\files are created immediately without touching anything. This one is intentional.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@unregd commented on GitHub (Dec 2, 2024):

When a torrent containing 0 length files is added these dirs\files are created immediately without touching anything.

This one is intentional.

Unfortunate, it leaves unwanted trash around. :/

@unregd commented on GitHub (Dec 2, 2024): > > When a torrent containing 0 length files is added these dirs\files are created immediately without touching anything. > > This one is intentional. Unfortunate, it leaves unwanted trash around. :/

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@stalkerok commented on GitHub (Dec 2, 2024):

Unfortunate, it leaves unwanted trash around. :/

What does that mean? If you delete the torrent along with the data, this file is also deleted.
(can't find a related issue)

@stalkerok commented on GitHub (Dec 2, 2024): > Unfortunate, it leaves unwanted trash around. :/ What does that mean? If you delete the torrent along with the data, this file is also deleted. (can't find a related issue)

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@unregd commented on GitHub (Dec 2, 2024):

Unfortunate, it leaves unwanted trash around. :/

What does that mean? If you delete the torrent along with the data, this file is also deleted. (can't find a related issue)

The automatically added torrents, in stopped state, create files before they are decided to be downloaded or deleted (from the queue). I don't expect files to be created without actually starting the download.

@unregd commented on GitHub (Dec 2, 2024): > > Unfortunate, it leaves unwanted trash around. :/ > > What does that mean? If you delete the torrent along with the data, this file is also deleted. (can't find a related issue) The automatically added torrents, in stopped state, create files before they are decided to be downloaded or deleted (from the queue). I don't expect files to be created without actually starting the download.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@stalkerok commented on GitHub (Dec 2, 2024):

In any case, that's irrelevant to this issue.

@stalkerok commented on GitHub (Dec 2, 2024): In any case, that's irrelevant to this issue.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@unregd commented on GitHub (Dec 2, 2024):

In any case, that's irrelevant to this issue.

I can see it now. The description fits, only the reproduction steps tell the difference.

@unregd commented on GitHub (Dec 2, 2024): > In any case, that's irrelevant to this issue. I can see it now. The description fits, only the reproduction steps tell the difference.

deekerman commented

2026-02-22 03:03:21 -05:00

Author

Owner

@stalkerok commented on GitHub (Dec 13, 2024):

@thalieht please add the libtorrent label.

@stalkerok commented on GitHub (Dec 13, 2024): @thalieht please add the libtorrent label.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@superbonaci commented on GitHub (Jul 9, 2025):

This is also related to : https://github.com/qbittorrent/qBittorrent/issues/19398

The option Pre-allocate behaves differently depending on operating system and filesystem involved, and also depends on each filesystem capabilities, like sparse files, compression, deduplication, so on...

@superbonaci commented on GitHub (Jul 9, 2025): This is also related to : https://github.com/qbittorrent/qBittorrent/issues/19398 The option `Pre-allocate` behaves differently depending on operating system and filesystem involved, and also depends on each filesystem capabilities, like sparse files, compression, deduplication, so on...

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Sep 2, 2025):

This can not be fixed on qBittorrent side.

@HanabishiRecca commented on GitHub (Sep 2, 2025): This can not be fixed on qBittorrent side.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Sep 2, 2025):

How do you know this?

Because qBittorrent doesn't do anything on its own here, it only sets native libtorrent file priorities. All I/O operations with files content and allocation are performed by libtorrent.

Assuming it is true, what would be the correct procedure here?

Report the problem to libtorrent.

Has this been reported to whoever would be responsible for fixing this behavior?

I guess noone cared enough to do that. At least no mentions could be seen in this issue.
Good luck with that though, especially if you want the possible fix to be backported to 1.2.

@HanabishiRecca commented on GitHub (Sep 2, 2025): > How do you know this? Because qBittorrent doesn't do anything on its own here, it only sets native libtorrent file priorities. All I/O operations with files content and allocation are performed by libtorrent. > Assuming it is true, what would be the correct procedure here? Report the problem to [libtorrent](https://github.com/arvidn/libtorrent). > Has this been reported to whoever would be responsible for fixing this behavior? I guess noone cared enough to do that. At least no mentions could be seen in this issue. Good luck with that though, especially if you want the possible fix to be backported to 1.2.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@martingalvan commented on GitHub (Sep 2, 2025):

Has this been reported to whoever would be responsible for fixing this behavior?

I guess noone cared enough to do that. At least no mentions could be seen in this issue. Good luck with that though, especially if you want the possible fix to be backported to 1.2.

Will do, thanks.

@martingalvan commented on GitHub (Sep 2, 2025): > > Has this been reported to whoever would be responsible for fixing this behavior? > > I guess noone cared enough to do that. At least no mentions could be seen in this issue. Good luck with that though, especially if you want the possible fix to be backported to 1.2. Will do, thanks.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Sep 2, 2025):

Well, quick analyze of libtorrent's code reveals why this happens.

When you change priority from "do not download" to something else, libtorrent tries to move existing data from .parts file to the actual file. But it does not know in advance if there is any data, so creates/allocates the file anyway.

This is a very important function and I'm not sure if its behavior could be changed easily, if at all.

@HanabishiRecca commented on GitHub (Sep 2, 2025): Well, quick analyze of libtorrent's [code](https://github.com/arvidn/libtorrent/blob/1b5ab9f0080050eb99f5a8a0af48087ad98c33c6/src/mmap_storage.cpp#L176-L224) reveals why this happens. When you change priority from "do not download" to something else, libtorrent tries to move existing data from `.parts` file to the actual file. But it does not know in advance if there is any data, so creates/allocates the file anyway. This is a very important function and I'm not sure if its behavior could be changed easily, if at all.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Sep 2, 2025):

One easy fix I see is to move the open_file call inside the if (m_part_file && use_partfile(i)) condition. It should prevent files from creating when none of their parts are present in the .parts file.

But beside that, if some parts of the file are already present in .parts, I think nothing could be done here.

@HanabishiRecca commented on GitHub (Sep 2, 2025): One easy fix I see is to move the `open_file` call inside the `if (m_part_file && use_partfile(i))` condition. It should prevent files from creating when none of their parts are present in the `.parts` file. But beside that, if some parts of the file are already present in `.parts`, I think nothing could be done here.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Sep 2, 2025):

It should prevent files from creating

I tested it and that doesn't work though. Apparently, all files are set to use the partfile initially. So I don't see solutions for the problem, it inherently comes from how the partfile works.

But you still could report it. Maybe Arvid or someone else would come up with something. You could also link my messages.

@HanabishiRecca commented on GitHub (Sep 2, 2025): > It should prevent files from creating I tested it and that doesn't work though. Apparently, all files are [set to use the partfile initially](https://github.com/arvidn/libtorrent/blob/1b5ab9f0080050eb99f5a8a0af48087ad98c33c6/src/mmap_storage.cpp#L350). So I don't see solutions for the problem, it inherently comes from how the partfile works. But you still could report it. Maybe Arvid or someone else would come up with something. You could also link my messages.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@stalkerok commented on GitHub (Sep 2, 2025):

As far as I remember, there was a issue, but I can't find it. Perhaps I'm confusing it with something else, otherwise I would have related them.

@stalkerok commented on GitHub (Sep 2, 2025): As far as I remember, there was a issue, but I can't find it. Perhaps I'm confusing it with something else, otherwise I would have related them.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@l-n0-0b commented on GitHub (Sep 3, 2025):

it's good that it's as shown in the video.
This solves just my problem https://github.com/qbittorrent/qBittorrent/issues/23188

that the files, on the contrary, are created at the beginning of the download (when the speed appears) in a chaotic order and eventually do not fit on the disk.

@l-n0-0b commented on GitHub (Sep 3, 2025): it's good that it's as shown in the video. This solves just my problem https://github.com/qbittorrent/qBittorrent/issues/23188 - that the files, on the contrary, are created at the beginning of the download (when the speed appears) in a chaotic order and eventually do not fit on the disk.

deekerman commented

2026-02-22 03:03:22 -05:00

Author

Owner

@l-n0-0b commented on GitHub (Sep 3, 2025):

One easy fix I see is to move the open_file call inside the if (m_part_file && use_partfile(i)) condition. It should prevent files from creating when none of their parts are present in the .parts file.

But beside that, if some parts of the file are already present in .parts, I think nothing could be done here.

Sorry to interrupt. But I have a suggestion to create a 3 boot state as "pause", which will solve many problems.
Including this one, files will not be created in the "stop" state, they will be created "pause" state.
This will also be able to solve my other problems - including task freezes (which freezes the entire application) - work with 5 files will be paused (task freezes), and with 1 task continue to work. Etc. Thank you.

@l-n0-0b commented on GitHub (Sep 3, 2025): > One easy fix I see is to move the `open_file` call inside the `if (m_part_file && use_partfile(i))` condition. It should prevent files from creating when none of their parts are present in the `.parts` file. > > But beside that, if some parts of the file are already present in `.parts`, I think nothing could be done here. Sorry to interrupt. But I have a suggestion to create a 3 boot state as "pause", which will solve many problems. Including this one, files will not be created in the "stop" state, they will be created "pause" state. This will also be able to solve my other problems - including task freezes (which freezes the entire application) - work with 5 files will be paused (task freezes), and with 1 task continue to work. Etc. Thank you.