Re: Regression/Error on commons-io FileUtils.copyFile ?
I try to debug it to see what is the problem. Yes, looks that the timestamp isn't changed. destAttrView.setTimes(...) throws an java.nio.file.FileSystemException: /mnt/.../ficheros/0001.tif: Operación no permitida (Not allowed operation). Then targetFile.setLastModified(...) returns false. The mount folder has this options (taken frommount | grep MY_FOLDER) : cifs (rw,relatime,vers=3.0,cache=strict,username=X,domain=X,uid=1000,noforceuid,gid=1000,noforcegid,addr=XXX,file_mode=0777,dir_mode=0777,iocharset=utf8,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) Note that this happens on different versions of Ubuntu server (22.04LTS and 18.04LTS) El 30/11/23 a las 12:32, Gary Gregory escribió: Hello Luis, Thank you for your detailed report. An interesting question is to check to see if the file attributes are correctly updated using 2.11 or if the file timestamp is not changed and that fact is not reported as an exception. For a new feature, free to create a PR on GitHub so we can see what this would really look like. TY, Gary On Tue, Nov 28, 2023, 2:29 PM Luis Panadero Guardeño wrote: Good afternoon, I recently noticed a issue when we update our projects from Commons-io 2.11.0 to 2.13.0 with FileUtils.copyFile In our code base, we was using FileUtils.copyFile(src, dst) , that as is said on the JavaDoc, must preserve the file's last modified date/times. Sometimes, we do this over a SMB/CIFs share folder, and we never had problems or errors with this. But, since we update to 2.13.0 , we got IOExceptions because copyFile fails to preserve the file's last modified date/times. I see that the implementation changed a bit. on 2.11.0 copyFile uses directly File.setLastModified(long) and now tries with BasicFileAttributeView.setTimes(FileTime, FileTime, FileTime) and if fails, tries with File.setLastModified(long) . So, it should keep working exactly like before. But, obviously, for our use case, isn't. We workaround , calling copyFile with preserveFileDate set to false. Also, I noticed an problem with the actual API of FileUtils.copyFile methods. I think that an improvement should be that when copyFile fails to set file's last modified date/times, should throw a different exception from IOException (extend an exception from it). Actually it's imposible to differentiated from another bigger IO problems. In out case, we would like to try to preserve the file's last modified date/times, but ignore the error if it fails to do that. And I can't see any way of doing it. Specially with the current implementation of FileUtils.copyFile . -- /Luis Panadero Guardeño/ Departamento de Informática luis.panad...@digibis.com DIGIBÍS S.L. DIGIBÍS S.L.U. C/ Alenza, 4, 5ª planta. 28003 Madrid Tf. 91 432 08 88 . Fax 91 432 11 13 http://www.digibis.com Certificado ISO 9001. No imprimir si no es necesario. Protejamos el Medio Ambiente En cumplimiento de la LOPD y la LSSI, le informamos de que sus datos personales son incorporados a un fichero, titularidad de DIGIBÍS, S.L.U., con el fin de ofrecerle información sobre servicios que pueden ser de su interés. Podrá ejercitar sus derechos ARCO (de acceso, rectificación, cancelación y oposición) mediante un escrito dirigido a digi...@digibis.com , con copia del DNI o documento identificativo sustitutorio. En caso de querer darse de baja pinche aquí <mailto:digi...@digibis.com?subject=DAR%20DE%20BAJA>. -- /Luis Panadero Guardeño/ Departamento de Informática luis.panad...@digibis.com DIGIBÍS S.L. DIGIBÍS S.L.U. C/ Alenza, 4, 5ª planta. 28003 Madrid Tf. 91 432 08 88 . Fax 91 432 11 13 http://www.digibis.com Certificado ISO 9001. No imprimir si no es necesario. Protejamos el Medio Ambiente En cumplimiento de la LOPD y la LSSI, le informamos de que sus datos personales son incorporados a un fichero, titularidad de DIGIBÍS, S.L.U., con el fin de ofrecerle información sobre servicios que pueden ser de su interés. Podrá ejercitar sus derechos ARCO (de acceso, rectificación, cancelación y oposición) mediante un escrito dirigido a digi...@digibis.com , con copia del DNI o documento identificativo sustitutorio. En caso de querer darse de baja pinche aquí <mailto:digi...@digibis.com?subject=DAR%20DE%20BAJA>.
Regression/Error on commons-io FileUtils.copyFile ?
Good afternoon, I recently noticed a issue when we update our projects from Commons-io 2.11.0 to 2.13.0 with FileUtils.copyFile In our code base, we was using FileUtils.copyFile(src, dst) , that as is said on the JavaDoc, must preserve the file's last modified date/times. Sometimes, we do this over a SMB/CIFs share folder, and we never had problems or errors with this. But, since we update to 2.13.0 , we got IOExceptions because copyFile fails to preserve the file's last modified date/times. I see that the implementation changed a bit. on 2.11.0 copyFile uses directly File.setLastModified(long) and now tries with BasicFileAttributeView.setTimes(FileTime, FileTime, FileTime) and if fails, tries with File.setLastModified(long) . So, it should keep working exactly like before. But, obviously, for our use case, isn't. We workaround , calling copyFile with preserveFileDate set to false. Also, I noticed an problem with the actual API of FileUtils.copyFile methods. I think that an improvement should be that when copyFile fails to set file's last modified date/times, should throw a different exception from IOException (extend an exception from it). Actually it's imposible to differentiated from another bigger IO problems. In out case, we would like to try to preserve the file's last modified date/times, but ignore the error if it fails to do that. And I can't see any way of doing it. Specially with the current implementation of FileUtils.copyFile . -- /Luis Panadero Guardeño/ Departamento de Informática luis.panad...@digibis.com DIGIBÍS S.L. DIGIBÍS S.L.U. C/ Alenza, 4, 5ª planta. 28003 Madrid Tf. 91 432 08 88 . Fax 91 432 11 13 http://www.digibis.com Certificado ISO 9001. No imprimir si no es necesario. Protejamos el Medio Ambiente En cumplimiento de la LOPD y la LSSI, le informamos de que sus datos personales son incorporados a un fichero, titularidad de DIGIBÍS, S.L.U., con el fin de ofrecerle información sobre servicios que pueden ser de su interés. Podrá ejercitar sus derechos ARCO (de acceso, rectificación, cancelación y oposición) mediante un escrito dirigido a digi...@digibis.com , con copia del DNI o documento identificativo sustitutorio. En caso de querer darse de baja pinche aquí <mailto:digi...@digibis.com?subject=DAR%20DE%20BAJA>.
Re: [JEXL] Detecting infinite loops in JEXL Scripts
Probably you only can detect something trivial like a while(true) {... }
analyzing the code. But beyond that... Well it's the "Halting problem" (
https://en.wikipedia.org/wiki/Halting_problem ) :
In computability theory
,
the *halting problem* is the problem of determining, from a
description of an arbitrary computer program
and an input,
whether the program will finish running, or continue to run forever.
The halting problem is /undecidable
/, meaning that
no general algorithm
exists that solves the halting problem for all possible
program–input pairs.
El 7/8/23 a las 11:02, Aditya Kumar1 escribió:
Hi,
I am planning to use JEXL library in my SaaS based product to run
JavaScripts/JexlScripts(I understand, Jexl is not exactly java script).
Since, security is one of the most important requirements for any SaaS
based product, I am going to use Jexl Sandbox and Jexl Features to
secure my application. I see that in Jexl features, we have a way to
turn off the loops but for my requirement, I need to enable loops in
the scripts.
Is there a way detect infinite loops incase someone write’s such an
expression which turn into infinite loop during evaluation? Also,
someone can also try to sabotage our application by running infinite
loops. Is there a way to detect and avoid such a security issue?
PS: I would really appreciate if you could let me know any other
security aspects which I need to consider while using JEXL library.
Thanks,
Aditya
*—*
*Aditya Kumar1*
Technology Architect
Precisely.com
ATTENTION: -
The information contained in this message (including any files
transmitted with this message) may contain proprietary, trade secret
or other confidential and/or legally privileged information. Any
pricing information contained in this message or in any files
transmitted with this message is always confidential and cannot be
shared with any third parties without prior written approval from
Precisely. This message is intended to be read only by the individual
or entity to whom it is addressed or by their designee. If the reader
of this message is not the intended recipient, you are on notice that
any use, disclosure, copying or distribution of this message, in any
form, is strictly prohibited. If you have received this message in
error, please immediately notify the sender and/or Precisely and
destroy all copies of this message in your possession, custody or control.
Apache Commons JXPath , would be a new release ?
I just take a look that JXPatch had many commits on the last years (fixes, third party dependencies updated, tests...) but not was any new release since 2015 . JXPatch would get a new release any time ? -- /Luis Panadero Guardeño/ Departamento de Informática luis.panad...@digibis.com DIGIBÍS S.L. DIGIBÍS S.L.U. C/ Alenza, 4, 5ª planta. 28003 Madrid Tf. 91 432 08 88 . Fax 91 432 11 13 http://www.digibis.com Certificado ISO 9001. No imprimir si no es necesario. Protejamos el Medio Ambiente En cumplimiento de la LOPD y la LSSI, le informamos de que sus datos personales son incorporados a un fichero, titularidad de DIGIBÍS, S.L.U., con el fin de ofrecerle información sobre servicios que pueden ser de su interés. Podrá ejercitar sus derechos ARCO (de acceso, rectificación, cancelación y oposición) mediante un escrito dirigido a digi...@digibis.com , con copia del DNI o documento identificativo sustitutorio. En caso de querer darse de baja pinche aquí <mailto:digi...@digibis.com?subject=DAR%20DE%20BAJA>.
