Re: Strange FS download behaviour

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