[Gluster-devel] Simulating some kind of "virtual file"
Amar Tumballi
atumball at redhat.com
Wed Jan 10 13:16:28 UTC 2018
Check the files in $mountpoint/.meta/ directory. These are all virtual. And
meta xlator gives a very good idea about how to handle virtual files (and
directories).
-Amar
On Wed, Jan 10, 2018 at 6:36 PM, Xavi Hernandez <jahernan at redhat.com> wrote:
> Hi David,
>
> On Wed, Jan 10, 2018 at 1:42 PM, David Spisla <david.spisla at iternity.com>
> wrote:
>>
>> *[David Spisla] I tried this:*
>>
>> *char *new_path = malloc(1+len_path-5);*
>>
>> *memcpy(new_path, loc->path, len_path-5);*
>>
>> *new_path[strlen(new_path)] = '\0';*
>>
>> *loc->name = new_path + (len_path - len_name);*
>>
>>
>>
>> First of all, you should always use memory allocation functions from
>> gluster. This includes GF_MALLOC(), gf_strdup(), gf_asprintf() and several
>> other variants. You can look at libglusterfs/src/mem-pool.h to see all
>> available options.
>>
>>
>>
>> The second problem I see is that memcpy() doesn't write a terminating
>> null character, so when you compute strlen() afterwards, it will return
>> invalid length, or even try to access invalid memory, causing a crash.
>>
>>
>>
>> You should do something like this (assuming both loc->path and loc->name
>> are not NULL and skipping many necessary checks):
>>
>>
>>
>> len_path = strlen(loc->path);
>>
>> len_name = strlen(loc->name);
>>
>> new_path = GF_MALLOC(len_path - 4, gf_common_mt_char);
>>
>> memcpy(new_path, loc->path, len_path - 5);
>>
>> new_path[len_path - 5] = 0;
>>
>> loc->name = new_path + len_path - len_name;
>>
>>
>>
>> This should work fine.
>>
>>
>>
>> Xavi
>>
>> *[David Spisla] Yes, this worls fine. Thank you **😊**. By the way, is
>> there a way inside gluster xlator to get access to xattr or attr of a file.
>> In the lookup function there is only the struct loc, but I am missing there
>> the files gfid. It seems to be null always. I could use syncop_getxattr()
>> with the parameter loc, but the gfid is missing. Can I get the gfid if I
>> have only loc->path and loc-> name? It is like a conversion from files path
>> to files gfid.*
>>
>
> One of the main purposes of the 'lookup' fop is to resolve a given path to
> an existing gfid, so you won't find any gfid in the lookup request (unless
> it's a revalidate request). You need to look at the response (cbk) of the
> lookup to get the real gfid. If the request succeeds, you can find the gfid
> in buf->ia_gfid of the lookup callback.
>
> Other fops that receive a loc_t structure are normally called after a
> successful lookup, so loc->gfid and/or loc->inode->gfid should be set
> (unfortunately there isn't an homogeneous management of loc_t structures by
> xlators, so not always both fields are set).
>
> You can also request additional xattrs in the lookup request by adding
> them to the xdata dictionary. Their values will be returned in the xdata
> argument of the lookup callback.
>
> Xavi
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
--
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180110/dc289531/attachment-0001.html>
More information about the Gluster-devel
mailing list