Directory listing flavor is not recognized on a unix file system

[arkraft]

Hi! 👋

Firstly, thanks for your work on this project! 🙂

Today I used patch-package to patch basic-ftp@4.6.1 for the project I'm working on.

We have a customer FTP server which we try to read data from. Writing to the server is no problem at all, just reading from it does not work, as the directory listing flavor is not recognized. I can connect with any FTP client i tried and they seem to work. The problem is the way the permissions are listed, the last char is missing there which leads to the whole line not being recognized.

// this is what we get
drw-r--rw   1     root     root         0 Apr 21 19:31 Directory1

// this is what would work here
drw-r--rw-   1     root     root         0 Apr 21 19:31 Directory1

We solved this with path-package by making the signs in the last capture group optional, but the capture group itself is still there. So changing the regex solved the problem for us and the directory is now being read correctly.

Here is the diff that solved our problem:

diff --git a/node_modules/basic-ftp/dist/parseListUnix.js b/node_modules/basic-ftp/dist/parseListUnix.js
index 7cd7b5d..5d5a804 100644
--- a/node_modules/basic-ftp/dist/parseListUnix.js
+++ b/node_modules/basic-ftp/dist/parseListUnix.js
@@ -36,7 +36,7 @@ const JA_YEAR = "\u5e74";
  *    {@code @}   file has extended attributes
  */
 const RE_LINE = new RegExp("([bcdelfmpSs-])" // file type
-    + "(((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-])))\\+?" // permissions
+    + "(((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]))((r|-)(w|-)([xsStTL-]?)))\\+?" // permissions
     + "\\s*" // separator TODO why allow it to be omitted??
     + "(\\d+)" // link count
     + "\\s+" // separator

This issue body was partially generated by patch-package.

[patrickjuchli]

Thanks for the detailed issue, I'd like to merge this. We have to make sure the parser continues to work for "other" unix flavours though.

[arkraft]

I could open a PR with the change and an additional test case for this line, then we could see if the other tests fail. If you would be interested?

[patrickjuchli]

Sure!

[patrickjuchli]

Fixed in 5.0.0