When using vsftpd rather than pureftpd in IRMA, there is an issue with the file deletion. For example, the brain tries to delete the file fontend/dir1/frontend/dir1/file1 instead of frontend/dir1/file1.
The root of the problem seems to be that the return format of NLST frontend for vsftpd is:
frontend/dir1
frontend/dir2
frontend/dir3
and not:
dir1
dir2
dir3
which seems to be the format returned by pureftpd (according to the irma code, could you confirm?). I would say that both implementations can be OK, since the FTP RFCs are pretty ambiguous.
This means that to be implementation independent, irma.ftp.handler.FtpTls.list should either cd to the path, list the cwd (NLST without any argument) and cd back to the old cwd, or only keep the basename of the paths retrieved from ftps.nlst(path).
I think that being able to use any FTP implementation is quite an interesting point in such a modular architecture, and vsftpd is known to be a really good one. What do you think?
Hi,
When using
vsftpd
rather thanpureftpd
in IRMA, there is an issue with the file deletion. For example, the brain tries to delete the filefontend/dir1/frontend/dir1/file1
instead offrontend/dir1/file1
.The root of the problem seems to be that the return format of
NLST frontend
forvsftpd
is:and not:
which seems to be the format returned by
pureftpd
(according to theirma
code, could you confirm?). I would say that both implementations can be OK, since the FTP RFCs are pretty ambiguous.This means that to be implementation independent, irma.ftp.handler.FtpTls.list should either
cd
to the path, list thecwd
(NLST
without any argument) andcd
back to the oldcwd
, or only keep the basename of the paths retrieved fromftps.nlst(path)
.I think that being able to use any FTP implementation is quite an interesting point in such a modular architecture, and
vsftpd
is known to be a really good one. What do you think?Florent