gnunet-developers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]