Częściowy listing katalogu FTP z symbolami wieloznacznymi

Question

Najpierw zapytałem, czy: ftp directory listing timeout. Huge number of subdirs. Mam odpowiedź.

Nadal, ponieważ mogę mieć setki tysięcy obiektów FTP w katalogu, może to trwać naprawdę długo. Pomyślałem jednak, że możliwe jest odzyskanie wszystkich obiektów zaczynających się od "A", a następnie "B" itd. Podczas pobierania katalogów może rozpocząć przetwarzanie ich w innym wątku, nie czekając, aż uzyska całą listę .

Czy można wykonać listing katalogu FTP za pomocą symboli wieloznacznych przy użyciu standardu FtpWebRequest?

Answer 1

Najnowsza aktualizacja do FTP specification (RFC 3659) jawnie to zabrania. Z section 2.2.2 of that specification, titled "Wildcarding" (kopalni nacisk):

dla poleceń zdefiniowane w niniejszym opisie, wszystkie ścieżki: są traktowane dosłownie. Oznacza to, że w przypadku ścieżki podanej jako parametr do polecenia , plik, którego nazwa jest identyczna z podaną ścieżką, jest domyślny. Żadne znaki z nazwy ścieżki nie mogą być traktowane jako "magiczne", a zatem nie jest możliwe dopasowanie wzorca (poza dokładnością równości) między podaną ścieżką a plikami obecnymi w NVFS serwera FTP serwera .

Klienci pragną jakąś formę wzór dopasowania funkcjonalności muszą uzyskać listę właściwej katalogu lub katalogów i realizować własne nazwy pliku procedur selekcyjnych.

Powiedział, że jeśli serwer je obsługuje, można nadal korzystać z FtpWebRequest class, ale trzeba by przetworzyć odpowiedź sobie poradzić listę elementów, jak klasy .NET nie będzie zrozumieć rozszerzenia specyficzne dla serwera.

Answer 2

Specyfikacja FTP mówi, że argument do komend listy plików (LIST, NLIST, MLSD, itp.) Jest nazwą ścieżki. W związku z tym nie powinno być żadnych symboli wieloznacznych.

RFC 959 (LIST + NLIST):

2,2. Terminologia

...

pathname

Ścieżka jest określona jako ciąg znaków, który musi być wejście do systemu plików przez użytkownika w celu identyfikacji pliku. Nazwa ścieżki zwykle zawiera nazwy urządzeń i/lub katalogów oraz specyfikację nazwy pliku . Protokół FTP nie określa jeszcze standardowej konwencji pathname . Każdy użytkownik musi postępować zgodnie z konwencjami nazw plików systemów plików uczestniczących w przesyłaniu.

...

5.3.1.POLECENIA FTP

...

LIST [<SP> <pathname>] <CRLF>
NLST [<SP> <pathname>] <CRLF>

RFC 3659 (MLSD):

2.2.2. Dzikie karty

W przypadku poleceń zdefiniowanych w tej specyfikacji wszystkie nazwy ścieżek są traktowane dosłownie jako . Oznacza to, że w przypadku ścieżki podanej jako parametr do polecenia domyślny jest plik, którego nazwa jest identyczna z nazwą ścieżki podaną . Żadne znaki z nazwy ścieżki nie mogą być traktowane jako specjalne lub "magiczne", zatem nie jest możliwe dopasowanie wzorca (poza dokładnością ) między podaną ścieżką a plikami obecnymi w NVFS serwera FTP.

...

7,1. Format MLSx kupna

...

Składnia polecenia MLSx jest:

mlst    = "MLst" [ SP pathname ] CRLF 
mlsd    = "MLsD" [ SP pathname ] CRLF 

---

W praktyce jednak wiele serwerów FTP obsługuje wilcards w argumencie. Ale ponieważ specyfikacja na to nie pozwala, nie ma oczywiście ustawionego standardu dla obsługiwanych symboli wieloznacznych.

vsftpd obsługuje *, ? i {} z LIST. vsftpd nie obsługuje nowoczesnego MLSD.

proftpd obsługuje *, ? i []. Ale tylko dla LIST. W szczególności nie zezwala na stosowanie symboli wieloznacznych z nowoczesnymi MLSD z komentarzem:

RFC3659 jawnie NIE obsługuje znaków globalnych. Tak więc ostrzeż o tym, , ale pozwól, aby polecenie było nadal niezmienione.

pure-ftpd obsługuje *, ? i [] zarówno dla LIST i MLSD.

FileZilla serwer obsługuje * tylko zarówno LIST i MLSD.

---

Ale na ogół nie należy polegać na serwerze FTP, aby w ogóle obsługiwać dowolne znaki wieloznaczne.

Jedynym niezawodnym rozwiązaniem jest pobranie pełnej listy katalogów i filtrowanie plików lokalnie. Na przykład możesz użyć wyrażenia regularnego()