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/00000001.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=XXXXX,domain=XXXXX,uid=1000,noforceuid,gid=1000,noforcegid,addr=XXXXXXX,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
<luis.panad...@digibis.com> 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>.
