| Message ID | 20171103123009.18705-5-christian.storm@siemens.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [01/11] Lua: expose get_tmpdir() to Lua | expand |
On 03/11/2017 13:30, Christian Storm wrote: > In order to be able to call copyfile() from within a Lua handler > or when chaining handlers, i.e., calling a C handler from within > a Lua handler, the image shouldn't be extracted beforehand as > this extraction, e.g., moves img_type's offset so that the > Lua handler would have to seek back prior to calling, e.g., > copyfile(). > > Instead of extracting prior to calling the Lua handler, rely on > the Lua handler either to do or to instruct the image's extraction, > e.g., via calling copyfile(). > > NOTE: This is a change in behavior and breaks current Lua handler > deployments as they expect the image to be extracted. > > Signed-off-by: Christian Storm <christian.storm@siemens.com> > --- > corelib/lua_interface.c | 15 --------------- > 1 file changed, 15 deletions(-) > > diff --git a/corelib/lua_interface.c b/corelib/lua_interface.c > index 21c361f..85a1d36 100644 > --- a/corelib/lua_interface.c > +++ b/corelib/lua_interface.c > @@ -535,26 +535,11 @@ static int l_handler_wrapper(struct img_type *img, void *data) { > int res = 0; > lua_Number result; > int l_func_ref; > - int fdout; > - const char* TMPDIR = get_tmpdir(); > > if (!gL || !img || !data) { > return -1; > } > > - /* > - * if the image was not extracted, it loads > - * images from a storage. Extract the file > - * and copy it into TMPDIR > - */ > - if (!strlen(img->extract_file)) { > - snprintf(img->extract_file, sizeof(img->extract_file), "%s%s", > - TMPDIR, img->fname); > - fdout = openfileoutput(img->extract_file); > - res = extract_next_file(img->fdin, fdout, img->offset, 0, > - img->is_encrypted, img->sha256); > - } > - > l_func_ref = *((int*)data); > /* get the callback function */ > lua_rawgeti(gL, LUA_REGISTRYINDEX, l_func_ref ); > Applied to -master, thanks ! Best regards, Stefano Babic
diff --git a/corelib/lua_interface.c b/corelib/lua_interface.c index 21c361f..85a1d36 100644 --- a/corelib/lua_interface.c +++ b/corelib/lua_interface.c @@ -535,26 +535,11 @@ static int l_handler_wrapper(struct img_type *img, void *data) { int res = 0; lua_Number result; int l_func_ref; - int fdout; - const char* TMPDIR = get_tmpdir(); if (!gL || !img || !data) { return -1; } - /* - * if the image was not extracted, it loads - * images from a storage. Extract the file - * and copy it into TMPDIR - */ - if (!strlen(img->extract_file)) { - snprintf(img->extract_file, sizeof(img->extract_file), "%s%s", - TMPDIR, img->fname); - fdout = openfileoutput(img->extract_file); - res = extract_next_file(img->fdin, fdout, img->offset, 0, - img->is_encrypted, img->sha256); - } - l_func_ref = *((int*)data); /* get the callback function */ lua_rawgeti(gL, LUA_REGISTRYINDEX, l_func_ref );
In order to be able to call copyfile() from within a Lua handler or when chaining handlers, i.e., calling a C handler from within a Lua handler, the image shouldn't be extracted beforehand as this extraction, e.g., moves img_type's offset so that the Lua handler would have to seek back prior to calling, e.g., copyfile(). Instead of extracting prior to calling the Lua handler, rely on the Lua handler either to do or to instruct the image's extraction, e.g., via calling copyfile(). NOTE: This is a change in behavior and breaks current Lua handler deployments as they expect the image to be extracted. Signed-off-by: Christian Storm <christian.storm@siemens.com> --- corelib/lua_interface.c | 15 --------------- 1 file changed, 15 deletions(-)