Re: Strange FS download behaviour

I see.

After a brief look at gnunet-publish and the fs service API I think 
adding this is fine.


BR

Martin

Am 07.02.25 um 19:23 schrieb Alessio Vanni:
> 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
>