new torrents on exFAT drive yield "Errored: Operation not supported"

[lclem]

Please provide the following information

qBittorrent version and Operating System

4.3.3 macos 10.15.7 Catalina

If on linux, libtorrent-rasterbar and Qt version

(type here)

What is the problem

New torrents do not start and an error "Errored: Operation not supported" appears in the Status column.

What is the expected behavior

A newly added torrent should start downloading.

Steps to reproduce

Set the default download directory to an exFAT drive and add a new torrent for download.

Extra info(if any)

(type here)

[glassez]

@arvidn, does libtorrent have any restrictions on the type of file system?

[arvidn]

it's not supposed to. Although, it does try to set files to sparse mode, which presumably fails on FAT. I wouldn't expect failing to do so would be fatal though. Also, "sparse mode" is only a thing on windows, not MacOS, there sparse files are transparent.

@lclem Do you have the full error message from the log? The full error message should include which operation failed as well as the error code.

[lclem]

Many thanks @glassez and @arvidn for the quick reply! The error is

'File error alert. Torrent: "". File: "". Reason: file_fallocate () error: Operation not supported'

This happens when the option "Pre-allocate disk space for all files". I do not get any error when the option is off.

Perhaps for exFAT filesystems one should use another method to pre-allocate disk space?

[arvidn]

I see. The possible behaviors I can think of are:

1. Fail when a filesystem doesn't support pre-allocating files (current behavior).
2. Ignore failures of pre-allocating files, since it's just an optimization anyway
3. Fall back to writing zeros to files, from user space, in order to pre-allocate them

I'm leaning towards the current behavior (1) is the most desirable. My reasoning is that if the user chooses an option that isn't supported, the user is probably interested in knowing whether it works or not. And I don't think anyone ever want to write zeros to the file from user space.

If the user wants behavior (2), they can just disable the option instead.

Option (3) is so inefficient that I can't imagine any up-side of pre-allocating files would be worth it.

That said, the status column should probably contain the full error message, or at least indicate that it was pre-allocation that failed.

[lclem]

I agree with what you said. The only issue not addressed is that currently the download just stops when the error occurs. So two things need to be done:

1) Improve the error message pointing to the offending option. 2) Let the download continue even if this error (warning?) occurred.

[glassez]

@arvidn Well, it looks like it's a libtorrent problem. Or can we do something from our side?

[arvidn]

I'm open to be convinced that libtorrent should do something else (presumably ignore the error and keep going, and make pre-allocation best-effort). But I don't think the current behavior is clearly wrong, in fact, I'm leaning toward it being the most reasonable behavior.

What I think is tripping up users is that the full error message isn't easily available in the GUI, but can only be found in the log. That means understanding that the underlying cause is the pre-allocation setting.

An alternative behavior could be to treat pre-allocation as best-effort, unless the truncation is done because the file on disk is too large.

[lclem]

I don't think looking the log is very helpful at the moment. I correctly guessed where the issue was, but after all the log just said "file_fallocate". Even at the log level there should be more information clearly pointing to the actual issue.

BTW it does not seem very reasonable to me that one should look at the log for an error that ought to be shown in the main interface :)

[glassez]

BTW it does not seem very reasonable to me that one should look at the log for an error that ought to be shown in the main interface :)

Do you really think it would be better to show this whole bunch in the main interface? i.e. in the list of torrents, or where? And how should it be presented in your opinion?

I correctly guessed where the issue was, but after all the log just said "file_fallocate".

The problem is that we often can't reliably associate a particular low-level error with a specific user action (or application settings) to provide friendly messages.

But I don't think the current behavior is clearly wrong, in fact, I'm leaning toward it being the most reasonable behavior.

Provided that it should at least provide an accurate message that the problem is precisely due to an unsupported preallocation, isn't it?

[lclem]

OK but now we know that preallocation + exFAT won't work. Perhaps one could add this info next to the "pre-allocate" option?

Somehow it should be easier for the next user having this issue to understand it :)

[glassez]

Perhaps one could add this info next to the "pre-allocate" option?

👍

[glassez]

@qbittorrent/bug-handlers, have you any thoughts about it?

[arvidn]

would it help to change "file_fallocate" to "file_preallocate"? (here)

[arvidn]

OK but now we know that preallocation + exFAT won't work. Perhaps one could add this info next to the "pre-allocate" option?

I'm not convinced that this is precise enough. I bet pre-allocation works on exFAT on windows. Maybe even Linux.

[lclem]

OK but now we know that preallocation + exFAT won't work. Perhaps one could add this info next to the "pre-allocate" option?

I'm not convinced that this is precise enough. I bet pre-allocation works on exFAT on windows. Maybe even Linux.

OK maybe one could add a link within the generic "Errored: Operation not supported" in the main interface pointing to the log? And in the log, it seems to me that "file_preallocate" is still machine code to the casual user, what about an English sentence like "An error occurred while pre-allocating the file space. This has been reported to occur with exFAT+macOS. Try switching that option off."

On top of this, it would be so much better to turn this error into a warning and keep downloading even if pre-allocation fails. The current behaviour just does not let the download start, which is very painful :)

[arvidn]

And in the log, it seems to me that "file_preallocate" is still machine code to the casual user

Libtorrent issues a file_error_alert with the following information in it:

1. The system error code (which can be turned into a localized message)
2. The operation that failed with that error (which can be turned into a string, in this case "file_fallocate"). But you can really map these codes to any strings.
3. The filename (or a fixed string if the file isn't in the torrent file, such as "partfile")
4. handle to the torrent file
5. name of the torrent

All of these pieces can be put together to form a human readable error message.

[CubeBag]

I also receive this error when the pre-allocation option is turned off (macOS 12.0.1 Monterey, qB v.4.3.9). Sometimes it downloads for a few seconds and then errors. Edit: Never mind, it seems like torrents added with the option enabled persist in throwing this error even after turning the option off. Deleting and re-adding the torrents seems to fix

[arvidn]

@CubeBag you're saying that the "preallocate" option is not relevant. Saving torrents to an exFAT drive fails unconditionally. But you say deleting and re-adding makes it work. Do you delete the files on disk also? Can you tell which operation, specifically, is failing with "operation not supported"? I take it it's not the file_preallocate operation then, since it fails with that disabled too.

[kambala-decapitator]

still happens with 4.4.2 on macOS 12.4, error is about file_fallocate. First file from the torrent does get created on the disk though (filled with null bytes).

But you say deleting and re-adding makes it work. Do you delete the files on disk also?

yes, this helps, I deleted files on disk when deleting torrent.

[AdrianVaduva4k]

I am still experiencing this issue on macos 12.6 with qbittorernt 4.5.0. Cant figure it out why it only happens to some torrents and not all. Tried other torrent clients and it was working fine. Any updates on how to bypass/fix this issue?

[NikoMuffin]

@AdrianVaduva4k I am seeing the same thing. Any fix?