[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange FS download behaviour
From: |
Alessio Vanni |
Subject: |
Re: Strange FS download behaviour |
Date: |
Fri, 7 Feb 2025 19:23:04 +0100 |
Hello,
the wrapper is just a proposal and I don't really have strong feelings
about it, so if it's deemed not necessary that's fine.
The thing is not about safety, the API itself is not "unsafe" and the
wrapper is not "safe". It's just that since gnunet-publish uses share
tree items to publish a regular non-directory file and file
information structs can be created in three different ways (file, data
buffer and reader) I'd say it makes sense to have a fourth function to
create that struct from a share tree item too.
GNUnet itself as a platform has many convenience wrappers around OS
operations, etc. so adding one more should not bring harm.
In a way it's more about consistency in API design and its usage and
in my specific case it would've also made the whole thing less
error-prone as I would've noticed the path inconsistencies earlier.
Anyway, the issue has been solved so whether the wrapper is added or
not has not immediate consequences and it's more of a long-term thing;
if it's fine to add it I'll submit a proper patch.
Thanks,
A.V.
On 02/07/25 17:17, Martin Schanzenbach wrote:
Hi,
two things. First regarding the issue:
The proposed function is a simple wrapper, as you say.
I do not understand what the incorrect/dangerous use of
GNUNET_FS_file_information_create_from_file is supposed to be, given a
ShareTreeItem.
(the function is probably also better called
GNUNET_FS_file_information_create_from_share_tree_item)
If you can elaborate on that, I can make a call regarding the safety
of the API.
Regarding contributions, if you want it added, I would prefer a proper
patch (https://docs.gnunet.org/master/developers/contributing.html).
But right now, I do not thing there is value in the wrapper, because
we either hide an unsafe API behind it while the unsafe API is still
exposed, or you just incorrectly used the API due to some external
file hard/soft link circumstances and the API is fine.
BR
Martin