Ok, now I've found out what is the issue: the regexp pattern used by UnixFTPEntryParser assumes too much about the format of the date. In particular, it assumes that there are spaces inside the date or something like that. As I'm not much of a regexp expert, I cannot really pinpoint the problem with the pattern. But I can demonstrate the results from applying this pattern below.
This is the usual case that is parsed OK.
*entry*: -rw-r--r-- 1 1000 1000 27 Jan 24 11:31 messages.vsp
parsed into these variables:
typeStr=-
hardLinkCount=1
usr=1000
grp=1000
filesize=27
datestr=Jan 24 11:31
name=messages.vsp
endtoken=
This is the one that has issues. Lucky for me, the parser manages to "parse" the entries that represent symbolic links, as these entries seem to have enough spaces required by the regexp pattern. Although incorrectly, it nicely demonstrates the issue with the parser.
*entry*: lrwxrwxrwx 1 neeme neeme 23 2005-03-02 18:06 macros -> ../../../global/macros/
parsed into these variables:
typeStr=l
hardLinkCount=1
usr=neeme
grp=neeme
filesize=23
datestr=2005-03-02 18:06 macros
name=->
endtoken= ../../../global/macros/
Note that starting from datestr variable, the parsing is f**ked up...
How can we solve this issue? Make regexp pattern also configurable? Better suggestions?
Rgds, Neeme
Neeme Praks wrote:
I cannot give you access as it is inside our corporate firewall. So I guess I'll try to debug it on my own. :-)
I'll let you know when I have made some progress with that.
smime.p7s
Description: S/MIME Cryptographic Signature
