You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Steve Cohen <sc...@javactivity.org> on 2004/03/28 22:53:24 UTC
[net] [vote] Release Commons-Net 1.2
I would like to try and get a 1.2 release out the door, but the last
time I tried, it died for want of a second. I recognize that I was
probably throwing too many votes for you to deal with and trying to do too
much at once, in a self-imposed time-frame of frantically trying to get things
done before I started working again. Ironically, I've probably accomplished
more for commons-net since I started working again in February than I was
accomplishing at the end of January.
Anyway, here's what we've got for this release:
1. Refactoring in January of the whole Entry Parser thing. I think this is
much more solid and intuitive than it used to be.
2. Autodetection of system type - a BIG feature for the Ant user community
and others. We missed the last Ant release and I'd like not to miss another.
3. I fixed all of the bugs that the functional tests contributed by Jeff
Brekke in February uncovered.
4. We have a new parser! OS400, contributed by Mario Ivankovits.
5. A few miscellaneous bug fixes.
One thing I never did get nailed down was 1.1 compatibility. There were
issues with running under a JDK 1.1 JVM that I just couldn't solve. I asked
on this list, but no one responded. But I think this is a relatively low
priority, more of a "nice to have" than a prerequisite for a 1.2 release. We
have a label for 1.1 compatibility and can always work off that to prepare a
1.1 release when someone is able to address these issues, which are contained
in the attached zip file. For all I know these issues may be nothing more
than an incorrect JDK 1.1 setup under Linux (1.1 java compilers for Linux
came not from Sun but from Blackdown and were less stable than the Windows
releases).
Anyway, I would like to raise once again the issue of moving to a 1.2 release
of commons-net. Please let's capitalize on the momentum we have. I will not
bug you guys with a lot of votes.
Steve
PS. Note to Daniel Savarese: I originally tried to raise this issue in an
off-list email to you and Jeff Brekke. However, two attempts at that have
bounced back to me since yesterday. I don't know why, but there appears to
be some issue with your email address.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] [vote] Release Commons-Net 1.2
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
+1 to the 1.2 release.
I just committed changes to the build to use the commons-build stuff.
I've also pushed out the site. Let me know anyone sees any problems
with it.
http://jakarta.apache.org/commons/net/
>>>>> On Sun, 28 Mar 2004 14:53:24 -0600, Steve Cohen <sc...@javactivity.org> said:
> I would like to try and get a 1.2 release out the door, but the last
> time I tried, it died for want of a second. I recognize that I was
> probably throwing too many votes for you to deal with and trying to
> do too much at once, in a self-imposed time-frame of frantically
> trying to get things done before I started working again.
> Ironically, I've probably accomplished more for commons-net since I
> started working again in February than I was accomplishing at the
> end of January.
> Anyway, here's what we've got for this release:
> 1. Refactoring in January of the whole Entry Parser thing. I think
> this is much more solid and intuitive than it used to be.
> 2. Autodetection of system type - a BIG feature for the Ant user
> community and others. We missed the last Ant release and I'd like
> not to miss another.
> 3. I fixed all of the bugs that the functional tests contributed by
> Jeff Brekke in February uncovered.
> 4. We have a new parser! OS400, contributed by Mario Ivankovits.
> 5. A few miscellaneous bug fixes.
> One thing I never did get nailed down was 1.1 compatibility. There
> were issues with running under a JDK 1.1 JVM that I just couldn't
> solve. I asked on this list, but no one responded. But I think
> this is a relatively low priority, more of a "nice to have" than a
> prerequisite for a 1.2 release. We have a label for 1.1
> compatibility and can always work off that to prepare a 1.1 release
> when someone is able to address these issues, which are contained in
> the attached zip file. For all I know these issues may be nothing
> more than an incorrect JDK 1.1 setup under Linux (1.1 java compilers
> for Linux came not from Sun but from Blackdown and were less stable
> than the Windows releases).
> Anyway, I would like to raise once again the issue of moving to a
> 1.2 release of commons-net. Please let's capitalize on the momentum
> we have. I will not bug you guys with a lot of votes.
> Steve
> PS. Note to Daniel Savarese: I originally tried to raise this issue
> in an off-list email to you and Jeff Brekke. However, two attempts
> at that have bounced back to me since yesterday. I don't know why,
> but there appears to be some issue with your email address.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release
Commons-Net 1.2)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen schrieb:
>.... test listing when
>SYST returned "Windows" and trying both parsers. Or some other test. To be
>done in the factory.
>
>
But how would you know, that you are in an directory where you have the
permission to do the list command, or at least there are files within?
Depending on the host configuration and the url the user passed to
FTPClient, the directory might be secured or empty.
If you dont like to use the UnixFTPEntryParser directly (what i can
unsterstand) , what do you think about an NTUnixFTPEntryParser (which is
a copy) and use this instead. So changes in UnixFTPEntryParser might not
break the NT Parser - if this is what you are afraid.
I think this is most invasive as it does not
a) rely on any configuration of the host
b) involve any additional step in the communication between FTPClient
and the Parser
c) need to change any interface/implemenation beside the current
NTFTPEntryParser.
>The DIRSTYLE thing offends because it seems "invasive" but how invasive is it,
>really? If it only affects the single connection session (which is what I
>would assume), it's not so bad.
>
>
Yes, i have checked it, it only affects the single connection.
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release Commons-Net 1.2)
Posted by Steve Cohen <sc...@javactivity.org>.
I think having a Unix parser within the NT parser is not a good design. I
think the logical right place to do it is in the factory. Before I had heard
about DIRSTYLE I was envisioning a process of getting a test listing when
SYST returned "Windows" and trying both parsers. Or some other test. To be
done in the factory.
The DIRSTYLE thing offends because it seems "invasive" but how invasive is it,
really? If it only affects the single connection session (which is what I
would assume), it's not so bad.
On Thursday 01 April 2004 7:08 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >So let's here some more comments: how nasty is this DIRSTYLE toggling
> > thing that some of us are just hearing about for the first time now?
>
> I think we could live with this, but beside this, the question is too,
> how bad it is to implement.
>
> Currently we do have not instance of the FTPClient within the
> EntryParsers, so we have to change createFileEntryParser to
> a) pass a "subtype" (which depends on the host)
> b) to pass the FtpClient instance to do the syst/dirstyle command.
>
> or
>
> c) We do the following withing NTFTPEntryParser
>
> private final FTPFileEntryParser fallback = new UnixFTPEntryParser();
> private boolean unixStyle = false;
>
> public FTPFile parseFTPEntry(String entry)
> {
> if (!unixStyle && matches(entry))
> {
> FTPFile f = new FTPFile();
> ...cut....
> }
> else
> {
> unixStyle = true;
> return fallback.parseFTPEntry(entry);
> }
> }
>
>
> Then we do not have to rely on the dirstyle output, and do not have to
> change the interface to the DefaultFTPEntryParser.
> So the ugliness (if you call the above change so ;-) is within the
> initiator - the NTFTPEntryParser and the corresponding host ftp
> implementation :-)
>
>
> If you agree, i could send a patch.
>
> -- Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release
Commons-Net 1.2)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
>So let's here some more comments: how nasty is this DIRSTYLE toggling thing
>that some of us are just hearing about for the first time now?
>
>
I think we could live with this, but beside this, the question is too,
how bad it is to implement.
Currently we do have not instance of the FTPClient within the
EntryParsers, so we have to change createFileEntryParser to
a) pass a "subtype" (which depends on the host)
b) to pass the FtpClient instance to do the syst/dirstyle command.
or
c) We do the following withing NTFTPEntryParser
private final FTPFileEntryParser fallback = new UnixFTPEntryParser();
private boolean unixStyle = false;
public FTPFile parseFTPEntry(String entry)
{
if (!unixStyle && matches(entry))
{
FTPFile f = new FTPFile();
...cut....
}
else
{
unixStyle = true;
return fallback.parseFTPEntry(entry);
}
}
Then we do not have to rely on the dirstyle output, and do not have to
change the interface to the DefaultFTPEntryParser.
So the ugliness (if you call the above change so ;-) is within the
initiator - the NTFTPEntryParser and the corresponding host ftp
implementation :-)
If you agree, i could send a patch.
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release Commons-Net 1.2)
Posted by Steve Cohen <sc...@javactivity.org>.
I see your point, but it doesn't really solve the problem that I'm seeing.
Sure, it would make it easier for any halfway competent java programmer to
subclass the parser factory, but I believe most of our users are not in this
boat. They want to import our jar into some other application like Ant and
have it work seamlessly without configuration issues or writing code.
So while I'm not opposed to your change - if you submit it as a patch, I'll
commit it - it doesn't really get to the core of the problem that I've been
outlining - a truly automatic detection scheme.
So let's here some more comments: how nasty is this DIRSTYLE toggling thing
that some of us are just hearing about for the first time now?
On Thursday 01 April 2004 12:47 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >Wow, that's nasty. Or maybe not.
>
> I think using DIRSTYLE to toggle the output isnt that nice.
> Another idea could be to change the DefaultFTPEntryParserFactory to
> allow easier derivation..
>
> ---snip---
> public FTPFileEntryParser createFileEntryParser(String key)
> {
> Class parserClass = null;
> try {
> parserClass = Class.forName(key);
> return (FTPFileEntryParser) parserClass.newInstance();
> } catch (ClassNotFoundException e) {
> String ukey = null;
> if (null != key) {
> ukey = key.toUpperCase();
> }
> if (ukey.indexOf("UNIX") >= 0) {
> return createUnixFTPEntryParser();
> } else if (ukey.indexOf("VMS") >= 0) {
> return createVMSVersioningFTPEntryParser();
> } else if (ukey.indexOf("WINDOWS") >= 0) {
> return createNTFTPEntryParser();
> } else if (ukey.indexOf("OS/2") >= 0) {
> return createOS2FTPEntryParser();
> } else if (ukey.indexOf("OS/400") >= 0) {
> return createOS400FTPEntryParser();
> } else {
> throw new ParserInitializationException(
> "Unknown parser type: " + key);
> }
> } catch (ClassCastException e) {
> throw new ParserInitializationException(
> parserClass.getName()
> + " does not implement the interface "
> + "org.apache.commons.net.ftp.FTPFileEntryParser.", e);
> } catch (Throwable e) {
> throw new ParserInitializationException(
> "Error initializing parser", e);
> }
> }
>
> public FTPFileEntryParser createUnixFTPEntryParser()
> {
> return new UnixFTPEntryParser();
> }
>
> public FTPFileEntryParser createVMSVersioningFTPEntryParser()
> {
> return new VMSVersioningFTPEntryParser();
> }
>
> public FTPFileEntryParser createNTFTPEntryParser()
> {
> return new NTFTPEntryParser();
> }
>
> public FTPFileEntryParser createOS2FTPEntryParser()
> {
> return new OS2FTPEntryParser();
> }
>
> public FTPFileEntryParser createOS400FTPEntryParser()
> {
> return new OS400FTPEntryParser();
> }
> ---snip---
>
> That way, you still have the current behaviour, and one could easily
> override the function "createNTFTPEntryParser()" to return an
> UnixFTPEntryParser.
> People (including me) deriving from DefaultFTPEntryParserFactory also
> benefit from later added parsers.
>
>
> Ciao,
> Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Another idea: have all parsers on failure default to the unix parser?
>>>>> On Mon, 05 Apr 2004 08:07:22 +0200, Mario Ivankovits <ma...@ops.co.at> said:
> I would like to learn: Could one of you please explain me, why it is
> better to issue the DIRSTYLE command instead of a simple detection
> of the directory-listing using regular expression? Only two regular
> expressions are needet for this - both already exists!
> Thanks! Mario
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I agree, this is a cleaner solution. Lets give it a go.
>>>>> On Mon, 05 Apr 2004 20:19:58 -0500, Steve Cohen <sc...@javactivity.org> said:
> When I first read Mario's proposal I was totally against it. It
> seemed to me that it must be much more complicated than DIRSTYLE. I
> wrote a whole letter slamming the idea. Then I took a good look at
> Mario's patch.
> Now that I have looked it over, I am much more favorable to the idea
> and compliment Mario strongly on his design.
> However, there is still one problem that I see:
> I don't like the way the Composite parser can vary on every entry.
> Any time it fails to parse an entry, it reopens the question of what
> type of parser it is. I think the business about iterating through
> the possible parsers should only happen the first time through. In
> other words:
> public FTPFile parseFTPEntry(String listEntry) { if
> (cachedFtpFileEntryParser != null) { FTPFile matched =
> cachedFtpFileEntryParser.parseFTPEntry(listEntry); if (matched !=
> null) { return matched;
> }
> }
> // my changes begin here
> }
> else { // my changes end here for (int iterParser=0;
> iterParser < ftpFileEntryParsers.length; iterParser++) {
> FTPFileEntryParser ftpFileEntryParser =
> ftpFileEntryParsers[iterParser];
> FTPFile matched =
> ftpFileEntryParser.parseFTPEntry(listEntry); if (matched != null) {
> cachedFtpFileEntryParser = ftpFileEntryParser; return matched;
> }
> }
> return null;
> }
> Assuming that all tests pass, I would not have any problem
> committing this with my change.
> On Monday 05 April 2004 1:47 pm, Mario Ivankovits wrote:
>> Jeffrey D. Brekke wrote: >Go for it, I probably won't get around to
>> looking at it until tonight > (CST).
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=28215
>>
>> Documented within the Bug-Description and in
>> CompositeFileEntryParser.java
>>
>> -- Mario
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Steve Cohen <sc...@javactivity.org>.
When I first read Mario's proposal I was totally against it. It seemed to me
that it must be much more complicated than DIRSTYLE. I wrote a whole letter
slamming the idea. Then I took a good look at Mario's patch.
Now that I have looked it over, I am much more favorable to the idea and
compliment Mario strongly on his design.
However, there is still one problem that I see:
I don't like the way the Composite parser can vary on every entry. Any time
it fails to parse an entry, it reopens the question of what type of parser it
is. I think the business about iterating through the possible parsers should
only happen the first time through. In other words:
public FTPFile parseFTPEntry(String listEntry)
{
if (cachedFtpFileEntryParser != null)
{
FTPFile matched = cachedFtpFileEntryParser.parseFTPEntry(listEntry);
if (matched != null)
{
return matched;
}
}
// my changes begin here
}
else
{
// my changes end here
for (int iterParser=0; iterParser < ftpFileEntryParsers.length;
iterParser++)
{
FTPFileEntryParser ftpFileEntryParser = ftpFileEntryParsers[iterParser];
FTPFile matched = ftpFileEntryParser.parseFTPEntry(listEntry);
if (matched != null)
{
cachedFtpFileEntryParser = ftpFileEntryParser;
return matched;
}
}
return null;
}
Assuming that all tests pass, I would not have any problem committing this
with my change.
On Monday 05 April 2004 1:47 pm, Mario Ivankovits wrote:
> Jeffrey D. Brekke wrote:
> >Go for it, I probably won't get around to looking at it until tonight
> > (CST).
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=28215
>
> Documented within the Bug-Description and in CompositeFileEntryParser.java
>
> -- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Mario Ivankovits <ma...@ops.co.at>.
Jeffrey D. Brekke wrote:
>Go for it, I probably won't get around to looking at it until tonight (CST).
>
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=28215
Documented within the Bug-Description and in CompositeFileEntryParser.java
-- Mario
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Go for it, I probably won't get around to looking at it until tonight (CST).
>>>>> On Mon, 05 Apr 2004 17:14:53 +0200, Mario Ivankovits <ma...@ops.co.at> said:
> Jeffrey D. Brekke wrote:
>> I'd need a little time to explore.
>>
>>
> If you would like, i could add a CompositeParser to Bugzilla.
> -- Mario
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Mario Ivankovits <ma...@ops.co.at>.
Jeffrey D. Brekke wrote:
>I'd need a little time to explore.
>
>
If you would like, i could add a CompositeParser to Bugzilla.
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
>>>>> On Mon, 05 Apr 2004 15:40:38 +0200, Mario Ivankovits <ma...@ops.co.at> said:
> Jeffrey D. Brekke wrote:
>> Sounds like an interesting solution. Are you thinking that we'd
>> have the NT parser, on failure, delagate to the unix parser ( then
>> of course if that fails, give up )?
>>
> Yes - for sure, but this is something i already suggested last week
> (http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg38905.html)
> but Steven doesnt liked it
> (http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg38906.html)
> - i dont know why. Maybe my english isnt good enough to explain my
> thoughts and to convince him.
The DIRSTYLE is simple, but doesn't really fit with how our parser
discovery was setup. Duplicating the Unix parser doesn't seem right.
> To detach it from the unix-parser we could copy the unix-parser to
> an nt-unix-parser. So if the unix-parser changes in the future, this
> might not influence the nt-unix-parser. But this isnt necassary
> needet. Such a failure should be come up early enough by the unit
> tests.
I understand, but really think delegating to the existing unix parser
would be simpler.
> A general fallback to the unix-parser wasnt in my mind.
> I wanted to implement this behaviour only into the nt-parser - as
> this is the only known ftp-server (for me) which is able to switch
> the dirstyle.
> I thought: "If the nt-server do have such a feature, the nt-parser
> should try to handle this" - and since there is not ftp-client
> instance within the factory and/or parser class to issue the
> "dirstyle" - this has to be done by guessing using regular
> expressions. Which is also faster. This also preserves from some
> roundtrips (dirstyle command) with the server.
Yes, I see this now. I think the NT parser could really be a
composite parser, which would try to first use the DOS RE, otherwise
use the Unix RE. I may try to explore this, it would be more
realtime, evaluating each listing it recieved. This would also
provide support for the dirstyle changing on the fly. I'd need a little
time to explore.
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Mario Ivankovits <ma...@ops.co.at>.
Jeffrey D. Brekke wrote:
>Sounds like an interesting solution. Are you thinking that we'd have
>the NT parser, on failure, delagate to the unix parser ( then of
>course if that fails, give up )?
>
Yes - for sure, but this is something i already suggested last week
(http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg38905.html)
but Steven doesnt liked it
(http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg38906.html)
- i dont know why.
Maybe my english isnt good enough to explain my thoughts and to convince
him.
To detach it from the unix-parser we could copy the unix-parser to an
nt-unix-parser. So if the unix-parser changes in the future, this might
not influence the nt-unix-parser.
But this isnt necassary needet. Such a failure should be come up early
enough by the unit tests.
A general fallback to the unix-parser wasnt in my mind.
I wanted to implement this behaviour only into the nt-parser - as this
is the only known ftp-server (for me) which is able to switch the dirstyle.
I thought: "If the nt-server do have such a feature, the nt-parser
should try to handle this" - and since there is not ftp-client instance
within the factory and/or parser class to issue the "dirstyle" - this
has to be done by guessing using regular expressions.
Which is also faster.
This also preserves from some roundtrips (dirstyle command) with the server.
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Sounds like an interesting solution. Are you thinking that we'd have
the NT parser, on failure, delagate to the unix parser ( then of
course if that fails, give up )? Sort-of like a composite parser
which contains a list of parsers to try in order?
Otherwise, just using a RE to see if there is a match wouldn't be too
bad either.
>>>>> On Mon, 05 Apr 2004 08:07:22 +0200, Mario Ivankovits <ma...@ops.co.at> said:
> I would like to learn: Could one of you please explain me, why it is
> better to issue the DIRSTYLE command instead of a simple detection
> of the directory-listing using regular expression? Only two regular
> expressions are needet for this - both already exists!
> Thanks! Mario
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Mario Ivankovits <ma...@ops.co.at>.
I would like to learn:
Could one of you please explain me, why it is better to issue the
DIRSTYLE command instead of a simple detection of the directory-listing
using regular expression?
Only two regular expressions are needet for this - both already exists!
Thanks!
Mario
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
I didn't end up with much free time this weekend, I did look and were
you thinking we would do this check in initiateListParsing?
>>>>> On Sat, 03 Apr 2004 12:48:50 -0600, Steve Cohen <sc...@javactivity.org> said:
> If not, I can do it. It's not a big change.
> On Friday 02 April 2004 8:18 pm, Jeffrey D. Brekke wrote:
>> OK, I'll see if I can get some time and do it this weekend.
>>
>> jb
>>
>> >>>>> On Thu, 01 Apr 2004 21:47:03 -0600, Steve Cohen >>>>>
>> <sc...@javactivity.org> said:
>> >
>> > Jeff, I agree with you. #2 is simple to implement, fits into the
>> > parser factory structure nicely and has no drawbacks that I can
>> see. > I also verified that it has no side effects. That is, a
>> second > connection gets the default dirstyle even if a previous,
>> and still > active connection has changed it. I will make the
>> change in time > for the release unless you want to do it. And we
>> can catch any > exception that might be thrown if some server did
>> not support site > dirstyle.
>> >
>> > I don't think anyone would object to using Dirstyle if Microsoft
>> had > provided a method to query the dirstyle without changing it,
>> but, we > can only play the hand we're dealt.
>> >
>> > +1 for #2
>> >
>> > On Thursday 01 April 2004 8:24 am, Jeffrey D. Brekke wrote:
>> >> >>>>> On Wed, 31 Mar 2004 22:22:24 -0600, Steve Cohen >>>>>
>> >>
>> >> <sc...@javactivity.org> said: >> > Wow, that's nasty. Or maybe
>> not. It sounds like there is a
>> >>
>> >> default > admin setting you can make and then the site DIRSTYLE
>> >> command > toggles the feature on and off for the duration of the
>> >> connection, > right?
>> >>
>> >> Yes, it only effects your connection. Since each time you call
>> >> 'site dirstyle' it toggles, in the original code snippet I was
>> >> calling 'site dirstyle' twice, just to determine what the
>> current >> setting is, *not* change it ( although it is changed for
>> a short >> while ). You are correct and the administrator can have
>> a site >> default to either Unix or MSDOS style listings. We are
>> currently >> using this method and haven't had trouble.
>> >>
>> >> > I see several ways we could go.
>> >> >
>> >> > 1. Just leave it as it is. (safest?) > 2. try your test (if
>> >>
>> >> SYST returns "Windows") and then pick the > appropriate parser.
>> > >> 3. If SYST returns Windows, run the site DIRSTYLE command once
>> > or >> twice as needed to force the session into UNIX mode and
>> >>
>> >> use the Unix parser.
>> >>
>> >> > 4. If SYST returns Windows, run the site DIRSTYLE command once
>> or >> > twice as needed to force the session into Windows mode and
>> use >
>> >>
>> >> the NT parser.
>> >>
>> >> I vote 2.
>> >>
>> >> > I am assuming that calling the DIRSTYLE command is only for
>> that >> > session, right? Do all versions of NT (4.0, 2K, XP,
>> etc.)
>> >>
>> >> support > this command?
>> >>
>> >> I've seen this dirstyle setting on all Microsoft Windows FTP >>
>> servers I've come across so far.
>> >>
>> >> > What is your recommendation? I think we should take your >
>> >>
>> >> recommendation here as you seem to have the most knowledge. It
>> > >> sounds like we could get such a change in and not delay the
>> release
>> >>
>> >> > if you are willing to test this in action. Does that make
>> sense
>> >>
>> >> - > or should we just leave it alone for now.
>> >>
>> >> I think we ( [net] ) shouldn't switch the users current dirstyle
>> on >> them. Lets use this method to determine what the current
>> dirstyle >> is and then give the user the correct parser. We never
>> want the >> inquiry to blow up, so we should default to NT's
>> Parser. I'll test >> and/or write up an additional test for our
>> functional suite.
>> >>
>> >> > What I am trying to avoid is causing trouble for our poor user
>> >>
>> >> last > week who just "solved" the problem using our earlier
>> version >> by > switching to unix mode on his server, and will now
>> be broken >> by our > fix.
>> >>
>> >> We ( at work ) are currently using 'site dirstyle' in some cases
>> to >> programmatically force the site to unix listings ( your
>> solution 3 >> ) in order to use the original list parsers ( yea, we
>> still have >> some old stuff using the old parsers! ).
>> >>
>> >> > On Wednesday 31 March 2004 1:05 pm, Jeffrey D. Brekke wrote:
>> >> >> The only way we've found is to use the output of the SITE
>> >>
>> >> DIRSTYLE >> command itself, calling it twice:
>>
ftp> site DIRSTYLE
>> >> >> 200 MSDOS-like directory output is off
>>
ftp> site DIRSTYLE
>> >> >> 200 MSDOS-like directory output is on
>> >> >>
>> >> >> Then parse that last line:
>> >> >>
>> >> >> /** * Method isMSDOSDirstyle. * @return String */ public
>> >>
>> >> boolean >> isMSDOSDirstyle() { boolean retVal = false; try { if
>> >> >> (sendSiteCommand("DIRSTYLE")) { sendSiteCommand("DIRSTYLE");
>> retVal
>> >>
>> >> >> = (getReplyString().indexOf("on") > 0);
>> >> >> }
>> >> >> }
>> >> >> catch (IOException e) { retVal = false;
>> >> >> }
>> >> >> return (retVal);
>> >> >> }
>> >> >>
>> >> >> That might work nicely, until the output of site DIRSTYLE
>> >>
>> >> changes >> ;)
>> >>
>> >> >> >>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen >>>>>
>> >> >>
>> >> >> <sc...@javactivity.org> said: >> > Maybe we're wrong to rely
>> >>
>> >> exclusively on the SYST command. Jeff, >> > since you evidently
>> >> have admin access to an NT FTP server, maybe
>> >>
>> >> >> you > can find a quick way to distinguish between an NT
>> server
>> >>
>> >> in >> Unix > DIRSTYLE mode and one in NT mode. LIke maybe the
>> >> header >> information > uses different text or something.
>> >>
>> >> >> > Maybe we could have something like this:
>> >> >> >
>> >> >> > if "Windows" == syst() result { // do a list command just
>> to
>> >>
>> >> look
>> >>
>> >> >> at > the header if header is unix style return unix else
>> return >> >> windows.
>> >> >>
>> >> >> > }
>> >> >> >
>> >> >> > If not, we can always go the FAQ route.
>> >> >> >
>> >> >> > Steve
>> >> >> >
>> >> >> > On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
>> >> >> >> Here on a Windows2003 server toggling the DIRSTYLE doesn't
>> >> >>
>> >> >> change >> the output of the SYS command. It still reports
>> >>
>> >> Windows >> NT 5.0, so >> if the MSDOS dirstyle is off, then the
>> >> wrong parser >> will get >> autoselected. I guess we could put
>> >> this in the FAQ or >> something >> with some examples maybe.
>> >>
>> >> >> >> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen
>> >>>>>
>> >> >> >>
>> >> >> >> <sc...@javactivity.org> said: >> > I think you may be
>> >>
>> >> referring
>> >>
>> >> >> to something said by a user last
>> >> >>
>> >> >> >> week, > in which he "solved" the problem by configuring
>> his
>> >>
>> >> NT
>> >>
>> >> >> FTP >> server to > use the "Unix display format". I didn't
>> know >> >> before >> that that was > an option. What I still don't
>> know is
>> >>
>> >> if >> one takes >> that option, > does the SYST command return
>> >> "Windows" >> or "Unix"? >> If it's the > former, then we have a
>> >> problem. It's >> not an >> unsolvable problem > because you can
>> >> always use the form >> of >> listFiles() that takes a > parser
>> >> class name or a different >> SYST >> value
>> (e.g. listFiles("UNIX")
>> >>
>> >> > ) as a parameter, although >> you >> can't at present do this
>> >>
>> >> from Ant. > (But adding this >> capability >> to Ant is what
>> I'm >> striving towards.)
>> >>
>> >> >> >> > A little investigation would be good here. But we need
>> to
>> >> >> >>
>> >> >> >> remember > the point of autodetection. It's not
>> foolproof,
>> >> >>
>> >> >> can't >> be foolproof, > since it depends on SYST
>> identification >> >> which is >> not necessarily > cast in stone.
>> It is an attempt
>> >>
>> >> to >> raise the >> default success rate > of using listFiles()
>> out >> of the >> box from >> maybe 90% to 98%, by > autodetecting
>> other >> cases, the >> most common >> of which is Windows but >
>> also OS2, >> VMS, OS400, etc. >> So while we >> need to strive to
>> become as > >> good as possible, I >> don't think we'll >> ever hit
>> 100%. FTP is >> too > loosely specced >> for that to happen.
>> >>
>> >> >> >> > Default falling back to unix if other methods fail would
>> >> >>
>> >> >> involve
>> >> >>
>> >> >> >> a > much more complex mechanism in which the program would
>> >>
>> >> have
>> >>
>> >> >> to
>> >> >>
>> >> >> >> > decide ("this isn't working") and try something else.
>> >>
>> >> While I
>> >>
>> >> >> >> wouldn't totally rule that out, I don't at present feel
>> there
>> >>
>> >> is
>> >>
>> >> >> > >> enough solid information to justify that effort.
>> >> >> > >>
>> >> >> >> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
>> >> >> >> >> +1
>> >> >> >> >>
>> >> >> >> >> >2. Autodetection of system type - a BIG feature for
>> the
>> >>
>> >> Ant
>> >>
>> >> >> >> user >> > community and others. We missed the last Ant
>> >>
>> >> release
>> >>
>> >> >> and >> I'd
>> >> >>
>> >> >> >> >> like not to > miss another.
>> >> >> >> >>
>> >> >> >> >> There is a littly thing whe should try to enhance in
>> the
>> >> >>
>> >> >> future. >> >> Using "Windows" for the NTFTPEntryParser is
>> too >> >> strict as it
>> >> >>
>> >> >> >> might >> depend on a "directory listing format" which is
>> >>
>> >> >>
>> >> >> configureable. >> Maybe a automatic fallback to
>> >>
>> >> UnixFTPEntryParser
>> >>
>> >> >> >> might help here?
>> >> >> >>
>> >> >> >> >> -- Mario
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> >> >> >> To unsubscribe, e-mail:
>> >> >> >>
>> >> >> >> commons-dev-unsubscribe@jakarta.apache.org >> For
>> additional
>> >> >>
>> >> >> commands, e-mail: >> commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> >> >> > To unsubscribe, e-mail:
>> >> >> >>
>> >> >> >> commons-dev-unsubscribe@jakarta.apache.org > For
>> additional
>> >> >>
>> >> >> commands, e-mail: commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> >> > To unsubscribe, e-mail:
>> >> >>
>> >> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> >>
>> >>
>> >> commands, e-mail: commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> > To unsubscribe, e-mail:
>> >>
>> >> commons-dev-unsubscribe@jakarta.apache.org > For additional >>
>> commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> commands, e-mail: commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Steve Cohen <sc...@javactivity.org>.
If not, I can do it. It's not a big change.
On Friday 02 April 2004 8:18 pm, Jeffrey D. Brekke wrote:
> OK, I'll see if I can get some time and do it this weekend.
>
> jb
>
> >>>>> On Thu, 01 Apr 2004 21:47:03 -0600, Steve Cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > Jeff, I agree with you. #2 is simple to implement, fits into the
> > parser factory structure nicely and has no drawbacks that I can see.
> > I also verified that it has no side effects. That is, a second
> > connection gets the default dirstyle even if a previous, and still
> > active connection has changed it. I will make the change in time
> > for the release unless you want to do it. And we can catch any
> > exception that might be thrown if some server did not support site
> > dirstyle.
> >
> > I don't think anyone would object to using Dirstyle if Microsoft had
> > provided a method to query the dirstyle without changing it, but, we
> > can only play the hand we're dealt.
> >
> > +1 for #2
> >
> > On Thursday 01 April 2004 8:24 am, Jeffrey D. Brekke wrote:
> >> >>>>> On Wed, 31 Mar 2004 22:22:24 -0600, Steve Cohen >>>>>
> >>
> >> <sc...@javactivity.org> said:
> >> > Wow, that's nasty. Or maybe not. It sounds like there is a
> >>
> >> default > admin setting you can make and then the site DIRSTYLE
> >> command > toggles the feature on and off for the duration of the
> >> connection, > right?
> >>
> >> Yes, it only effects your connection. Since each time you call
> >> 'site dirstyle' it toggles, in the original code snippet I was
> >> calling 'site dirstyle' twice, just to determine what the current
> >> setting is, *not* change it ( although it is changed for a short
> >> while ). You are correct and the administrator can have a site
> >> default to either Unix or MSDOS style listings. We are currently
> >> using this method and haven't had trouble.
> >>
> >> > I see several ways we could go.
> >> >
> >> > 1. Just leave it as it is. (safest?) > 2. try your test (if
> >>
> >> SYST returns "Windows") and then pick the > appropriate parser. >
> >> 3. If SYST returns Windows, run the site DIRSTYLE command once > or
> >> twice as needed to force the session into UNIX mode and
> >>
> >> use the Unix parser.
> >>
> >> > 4. If SYST returns Windows, run the site DIRSTYLE command once or
> >> > twice as needed to force the session into Windows mode and use >
> >>
> >> the NT parser.
> >>
> >> I vote 2.
> >>
> >> > I am assuming that calling the DIRSTYLE command is only for that
> >> > session, right? Do all versions of NT (4.0, 2K, XP, etc.)
> >>
> >> support > this command?
> >>
> >> I've seen this dirstyle setting on all Microsoft Windows FTP
> >> servers I've come across so far.
> >>
> >> > What is your recommendation? I think we should take your >
> >>
> >> recommendation here as you seem to have the most knowledge. It >
> >> sounds like we could get such a change in and not delay the release
> >>
> >> > if you are willing to test this in action. Does that make sense
> >>
> >> - > or should we just leave it alone for now.
> >>
> >> I think we ( [net] ) shouldn't switch the users current dirstyle on
> >> them. Lets use this method to determine what the current dirstyle
> >> is and then give the user the correct parser. We never want the
> >> inquiry to blow up, so we should default to NT's Parser. I'll test
> >> and/or write up an additional test for our functional suite.
> >>
> >> > What I am trying to avoid is causing trouble for our poor user
> >>
> >> last > week who just "solved" the problem using our earlier version
> >> by > switching to unix mode on his server, and will now be broken
> >> by our > fix.
> >>
> >> We ( at work ) are currently using 'site dirstyle' in some cases to
> >> programmatically force the site to unix listings ( your solution 3
> >> ) in order to use the original list parsers ( yea, we still have
> >> some old stuff using the old parsers! ).
> >>
> >> > On Wednesday 31 March 2004 1:05 pm, Jeffrey D. Brekke wrote:
> >> >> The only way we've found is to use the output of the SITE
> >>
> >> DIRSTYLE >> command itself, calling it twice:
>
> ftp> site DIRSTYLE
>
> >> >> 200 MSDOS-like directory output is off
>
> ftp> site DIRSTYLE
>
> >> >> 200 MSDOS-like directory output is on
> >> >>
> >> >> Then parse that last line:
> >> >>
> >> >> /** * Method isMSDOSDirstyle. * @return String */ public
> >>
> >> boolean >> isMSDOSDirstyle() { boolean retVal = false; try { if >>
> >> (sendSiteCommand("DIRSTYLE")) { sendSiteCommand("DIRSTYLE"); retVal
> >>
> >> >> = (getReplyString().indexOf("on") > 0);
> >> >> }
> >> >> }
> >> >> catch (IOException e) { retVal = false;
> >> >> }
> >> >> return (retVal);
> >> >> }
> >> >>
> >> >> That might work nicely, until the output of site DIRSTYLE
> >>
> >> changes >> ;)
> >>
> >> >> >>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen >>>>>
> >> >>
> >> >> <sc...@javactivity.org> said: >> > Maybe we're wrong to rely
> >>
> >> exclusively on the SYST command. Jeff, >> > since you evidently
> >> have admin access to an NT FTP server, maybe
> >>
> >> >> you > can find a quick way to distinguish between an NT server
> >>
> >> in >> Unix > DIRSTYLE mode and one in NT mode. LIke maybe the
> >> header >> information > uses different text or something.
> >>
> >> >> > Maybe we could have something like this:
> >> >> >
> >> >> > if "Windows" == syst() result { // do a list command just to
> >>
> >> look
> >>
> >> >> at > the header if header is unix style return unix else return
> >> >> windows.
> >> >>
> >> >> > }
> >> >> >
> >> >> > If not, we can always go the FAQ route.
> >> >> >
> >> >> > Steve
> >> >> >
> >> >> > On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
> >> >> >> Here on a Windows2003 server toggling the DIRSTYLE doesn't
> >> >>
> >> >> change >> the output of the SYS command. It still reports
> >>
> >> Windows >> NT 5.0, so >> if the MSDOS dirstyle is off, then the
> >> wrong parser >> will get >> autoselected. I guess we could put
> >> this in the FAQ or >> something >> with some examples maybe.
> >>
> >> >> >> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen >>>>>
> >> >> >>
> >> >> >> <sc...@javactivity.org> said: >> > I think you may be
> >>
> >> referring
> >>
> >> >> to something said by a user last
> >> >>
> >> >> >> week, > in which he "solved" the problem by configuring his
> >>
> >> NT
> >>
> >> >> FTP >> server to > use the "Unix display format". I didn't know
> >> >> before >> that that was > an option. What I still don't know is
> >>
> >> if >> one takes >> that option, > does the SYST command return
> >> "Windows" >> or "Unix"? >> If it's the > former, then we have a
> >> problem. It's >> not an >> unsolvable problem > because you can
> >> always use the form >> of >> listFiles() that takes a > parser
> >> class name or a different >> SYST >> value (e.g. listFiles("UNIX")
> >>
> >> > ) as a parameter, although >> you >> can't at present do this
> >>
> >> from Ant. > (But adding this >> capability >> to Ant is what I'm
> >> striving towards.)
> >>
> >> >> >> > A little investigation would be good here. But we need to
> >> >> >>
> >> >> >> remember > the point of autodetection. It's not foolproof,
> >> >>
> >> >> can't >> be foolproof, > since it depends on SYST identification
> >> >> which is >> not necessarily > cast in stone. It is an attempt
> >>
> >> to >> raise the >> default success rate > of using listFiles() out
> >> of the >> box from >> maybe 90% to 98%, by > autodetecting other
> >> cases, the >> most common >> of which is Windows but > also OS2,
> >> VMS, OS400, etc. >> So while we >> need to strive to become as >
> >> good as possible, I >> don't think we'll >> ever hit 100%. FTP is
> >> too > loosely specced >> for that to happen.
> >>
> >> >> >> > Default falling back to unix if other methods fail would
> >> >>
> >> >> involve
> >> >>
> >> >> >> a > much more complex mechanism in which the program would
> >>
> >> have
> >>
> >> >> to
> >> >>
> >> >> >> > decide ("this isn't working") and try something else.
> >>
> >> While I
> >>
> >> >> >> wouldn't totally rule that out, I don't at present feel there
> >>
> >> is
> >>
> >> >> > >> enough solid information to justify that effort.
> >> >> > >>
> >> >> >> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
> >> >> >> >> +1
> >> >> >> >>
> >> >> >> >> >2. Autodetection of system type - a BIG feature for the
> >>
> >> Ant
> >>
> >> >> >> user >> > community and others. We missed the last Ant
> >>
> >> release
> >>
> >> >> and >> I'd
> >> >>
> >> >> >> >> like not to > miss another.
> >> >> >> >>
> >> >> >> >> There is a littly thing whe should try to enhance in the
> >> >>
> >> >> future. >> >> Using "Windows" for the NTFTPEntryParser is too
> >> >> strict as it
> >> >>
> >> >> >> might >> depend on a "directory listing format" which is >>
> >> >>
> >> >> configureable. >> Maybe a automatic fallback to
> >>
> >> UnixFTPEntryParser
> >>
> >> >> >> might help here?
> >> >> >>
> >> >> >> >> -- Mario
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> >> >> To unsubscribe, e-mail:
> >> >> >>
> >> >> >> commons-dev-unsubscribe@jakarta.apache.org >> For additional
> >> >>
> >> >> commands, e-mail: >> commons-dev-help@jakarta.apache.org
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> >> > To unsubscribe, e-mail:
> >> >> >>
> >> >> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
> >> >>
> >> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail:
> >> >>
> >> >> commons-dev-unsubscribe@jakarta.apache.org > For additional >>
> >>
> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > To unsubscribe, e-mail:
> >>
> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
OK, I'll see if I can get some time and do it this weekend.
jb
>>>>> On Thu, 01 Apr 2004 21:47:03 -0600, Steve Cohen <sc...@javactivity.org> said:
> Jeff, I agree with you. #2 is simple to implement, fits into the
> parser factory structure nicely and has no drawbacks that I can see.
> I also verified that it has no side effects. That is, a second
> connection gets the default dirstyle even if a previous, and still
> active connection has changed it. I will make the change in time
> for the release unless you want to do it. And we can catch any
> exception that might be thrown if some server did not support site
> dirstyle.
> I don't think anyone would object to using Dirstyle if Microsoft had
> provided a method to query the dirstyle without changing it, but, we
> can only play the hand we're dealt.
> +1 for #2
> On Thursday 01 April 2004 8:24 am, Jeffrey D. Brekke wrote:
>> >>>>> On Wed, 31 Mar 2004 22:22:24 -0600, Steve Cohen >>>>>
>> <sc...@javactivity.org> said:
>> >
>> > Wow, that's nasty. Or maybe not. It sounds like there is a
>> default > admin setting you can make and then the site DIRSTYLE
>> command > toggles the feature on and off for the duration of the
>> connection, > right?
>>
>> Yes, it only effects your connection. Since each time you call
>> 'site dirstyle' it toggles, in the original code snippet I was
>> calling 'site dirstyle' twice, just to determine what the current
>> setting is, *not* change it ( although it is changed for a short
>> while ). You are correct and the administrator can have a site
>> default to either Unix or MSDOS style listings. We are currently
>> using this method and haven't had trouble.
>>
>> > I see several ways we could go.
>> >
>> > 1. Just leave it as it is. (safest?) > 2. try your test (if
>> SYST returns "Windows") and then pick the > appropriate parser. >
>> 3. If SYST returns Windows, run the site DIRSTYLE command once > or
>> twice as needed to force the session into UNIX mode and
>>
>> use the Unix parser.
>>
>> > 4. If SYST returns Windows, run the site DIRSTYLE command once or
>> > twice as needed to force the session into Windows mode and use >
>> the NT parser.
>>
>> I vote 2.
>>
>> > I am assuming that calling the DIRSTYLE command is only for that
>> > session, right? Do all versions of NT (4.0, 2K, XP, etc.)
>> support > this command?
>>
>> I've seen this dirstyle setting on all Microsoft Windows FTP
>> servers I've come across so far.
>>
>> > What is your recommendation? I think we should take your >
>> recommendation here as you seem to have the most knowledge. It >
>> sounds like we could get such a change in and not delay the release
>> > if you are willing to test this in action. Does that make sense
>> - > or should we just leave it alone for now.
>>
>> I think we ( [net] ) shouldn't switch the users current dirstyle on
>> them. Lets use this method to determine what the current dirstyle
>> is and then give the user the correct parser. We never want the
>> inquiry to blow up, so we should default to NT's Parser. I'll test
>> and/or write up an additional test for our functional suite.
>>
>> > What I am trying to avoid is causing trouble for our poor user
>> last > week who just "solved" the problem using our earlier version
>> by > switching to unix mode on his server, and will now be broken
>> by our > fix.
>>
>> We ( at work ) are currently using 'site dirstyle' in some cases to
>> programmatically force the site to unix listings ( your solution 3
>> ) in order to use the original list parsers ( yea, we still have
>> some old stuff using the old parsers! ).
>>
>> > On Wednesday 31 March 2004 1:05 pm, Jeffrey D. Brekke wrote:
>> >> The only way we've found is to use the output of the SITE
>> DIRSTYLE >> command itself, calling it twice:
>>
ftp> site DIRSTYLE
>> >> 200 MSDOS-like directory output is off
>>
ftp> site DIRSTYLE
>> >> 200 MSDOS-like directory output is on
>> >>
>> >> Then parse that last line:
>> >>
>> >> /** * Method isMSDOSDirstyle. * @return String */ public
>> boolean >> isMSDOSDirstyle() { boolean retVal = false; try { if >>
>> (sendSiteCommand("DIRSTYLE")) { sendSiteCommand("DIRSTYLE"); retVal
>> >> = (getReplyString().indexOf("on") > 0);
>> >> }
>> >> }
>> >> catch (IOException e) { retVal = false;
>> >> }
>> >> return (retVal);
>> >> }
>> >>
>> >> That might work nicely, until the output of site DIRSTYLE
>> changes >> ;)
>> >>
>> >> >>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen >>>>>
>> >>
>> >> <sc...@javactivity.org> said: >> > Maybe we're wrong to rely
>> exclusively on the SYST command. Jeff, >> > since you evidently
>> have admin access to an NT FTP server, maybe
>> >>
>> >> you > can find a quick way to distinguish between an NT server
>> in >> Unix > DIRSTYLE mode and one in NT mode. LIke maybe the
>> header >> information > uses different text or something.
>> >>
>> >> > Maybe we could have something like this:
>> >> >
>> >> > if "Windows" == syst() result { // do a list command just to
>> look
>> >>
>> >> at > the header if header is unix style return unix else return
>> >> windows.
>> >>
>> >> > }
>> >> >
>> >> > If not, we can always go the FAQ route.
>> >> >
>> >> > Steve
>> >> >
>> >> > On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
>> >> >> Here on a Windows2003 server toggling the DIRSTYLE doesn't
>> >>
>> >> change >> the output of the SYS command. It still reports
>> Windows >> NT 5.0, so >> if the MSDOS dirstyle is off, then the
>> wrong parser >> will get >> autoselected. I guess we could put
>> this in the FAQ or >> something >> with some examples maybe.
>> >>
>> >> >> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen >>>>>
>> >> >>
>> >> >> <sc...@javactivity.org> said: >> > I think you may be
>> referring
>> >>
>> >> to something said by a user last
>> >>
>> >> >> week, > in which he "solved" the problem by configuring his
>> NT
>> >>
>> >> FTP >> server to > use the "Unix display format". I didn't know
>> >> before >> that that was > an option. What I still don't know is
>> if >> one takes >> that option, > does the SYST command return
>> "Windows" >> or "Unix"? >> If it's the > former, then we have a
>> problem. It's >> not an >> unsolvable problem > because you can
>> always use the form >> of >> listFiles() that takes a > parser
>> class name or a different >> SYST >> value (e.g. listFiles("UNIX")
>> > ) as a parameter, although >> you >> can't at present do this
>> from Ant. > (But adding this >> capability >> to Ant is what I'm
>> striving towards.)
>> >>
>> >> >> > A little investigation would be good here. But we need to
>> >> >>
>> >> >> remember > the point of autodetection. It's not foolproof,
>> >>
>> >> can't >> be foolproof, > since it depends on SYST identification
>> >> which is >> not necessarily > cast in stone. It is an attempt
>> to >> raise the >> default success rate > of using listFiles() out
>> of the >> box from >> maybe 90% to 98%, by > autodetecting other
>> cases, the >> most common >> of which is Windows but > also OS2,
>> VMS, OS400, etc. >> So while we >> need to strive to become as >
>> good as possible, I >> don't think we'll >> ever hit 100%. FTP is
>> too > loosely specced >> for that to happen.
>> >>
>> >> >> > Default falling back to unix if other methods fail would
>> >>
>> >> involve
>> >>
>> >> >> a > much more complex mechanism in which the program would
>> have
>> >>
>> >> to
>> >>
>> >> >> > decide ("this isn't working") and try something else.
>> While I
>> >> >>
>> >> >> wouldn't totally rule that out, I don't at present feel there
>> is
>> >> >>
>> >> > >> enough solid information to justify that effort.
>> >> > >>
>> >> >> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
>> >> >> >> +1
>> >> >> >>
>> >> >> >> >2. Autodetection of system type - a BIG feature for the
>> Ant
>> >> >>
>> >> >> user >> > community and others. We missed the last Ant
>> release
>> >>
>> >> and >> I'd
>> >>
>> >> >> >> like not to > miss another.
>> >> >> >>
>> >> >> >> There is a littly thing whe should try to enhance in the
>> >>
>> >> future. >> >> Using "Windows" for the NTFTPEntryParser is too
>> >> strict as it
>> >>
>> >> >> might >> depend on a "directory listing format" which is >>
>> >>
>> >> configureable. >> Maybe a automatic fallback to
>> UnixFTPEntryParser
>> >>
>> >> >> might help here?
>> >> >>
>> >> >> >> -- Mario
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> >> >> To unsubscribe, e-mail:
>> >> >>
>> >> >> commons-dev-unsubscribe@jakarta.apache.org >> For additional
>> >>
>> >>
>> >> commands, e-mail: >> commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> >> > To unsubscribe, e-mail:
>> >> >>
>> >> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> >>
>> >>
>> >> commands, e-mail: commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> > To unsubscribe, e-mail:
>> >>
>> >> commons-dev-unsubscribe@jakarta.apache.org > For additional >>
>> commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> commands, e-mail: commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE
Posted by Steve Cohen <sc...@javactivity.org>.
Jeff, I agree with you.
#2 is simple to implement, fits into the parser factory structure nicely and
has no drawbacks that I can see. I also verified that it has no side
effects. That is, a second connection gets the default dirstyle even if a
previous, and still active connection has changed it. I will make the change
in time for the release unless you want to do it. And we can catch any
exception that might be thrown if some server did not support site dirstyle.
I don't think anyone would object to using Dirstyle if Microsoft had provided
a method to query the dirstyle without changing it, but, we can only play the
hand we're dealt.
+1 for #2
On Thursday 01 April 2004 8:24 am, Jeffrey D. Brekke wrote:
> >>>>> On Wed, 31 Mar 2004 22:22:24 -0600, Steve Cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > Wow, that's nasty. Or maybe not. It sounds like there is a default
> > admin setting you can make and then the site DIRSTYLE command
> > toggles the feature on and off for the duration of the connection,
> > right?
>
> Yes, it only effects your connection. Since each time you call 'site
> dirstyle' it toggles, in the original code snippet I was calling 'site
> dirstyle' twice, just to determine what the current setting is, *not*
> change it ( although it is changed for a short while ). You are
> correct and the administrator can have a site default to either Unix
> or MSDOS style listings. We are currently using this method and
> haven't had trouble.
>
> > I see several ways we could go.
> >
> > 1. Just leave it as it is. (safest?)
> > 2. try your test (if SYST returns "Windows") and then pick the
> > appropriate parser.
> > 3. If SYST returns Windows, run the site DIRSTYLE command once
> > or twice as needed to force the session into UNIX mode and
>
> use the Unix parser.
>
> > 4. If SYST returns Windows, run the site DIRSTYLE command once or
> > twice as needed to force the session into Windows mode and use
> > the NT parser.
>
> I vote 2.
>
> > I am assuming that calling the DIRSTYLE command is only for that
> > session, right? Do all versions of NT (4.0, 2K, XP, etc.) support
> > this command?
>
> I've seen this dirstyle setting on all Microsoft Windows FTP servers
> I've come across so far.
>
> > What is your recommendation? I think we should take your
> > recommendation here as you seem to have the most knowledge. It
> > sounds like we could get such a change in and not delay the release
> > if you are willing to test this in action. Does that make sense -
> > or should we just leave it alone for now.
>
> I think we ( [net] ) shouldn't switch the users current dirstyle on
> them. Lets use this method to determine what the current dirstyle is
> and then give the user the correct parser. We never want the inquiry
> to blow up, so we should default to NT's Parser. I'll test and/or
> write up an additional test for our functional suite.
>
> > What I am trying to avoid is causing trouble for our poor user last
> > week who just "solved" the problem using our earlier version by
> > switching to unix mode on his server, and will now be broken by our
> > fix.
>
> We ( at work ) are currently using 'site dirstyle' in some cases to
> programmatically force the site to unix listings ( your solution 3 )
> in order to use the original list parsers ( yea, we still have some
> old stuff using the old parsers! ).
>
> > On Wednesday 31 March 2004 1:05 pm, Jeffrey D. Brekke wrote:
> >> The only way we've found is to use the output of the SITE DIRSTYLE
> >> command itself, calling it twice:
>
> ftp> site DIRSTYLE
>
> >> 200 MSDOS-like directory output is off
>
> ftp> site DIRSTYLE
>
> >> 200 MSDOS-like directory output is on
> >>
> >> Then parse that last line:
> >>
> >> /** * Method isMSDOSDirstyle. * @return String */ public boolean
> >> isMSDOSDirstyle() { boolean retVal = false; try { if
> >> (sendSiteCommand("DIRSTYLE")) { sendSiteCommand("DIRSTYLE"); retVal
> >> = (getReplyString().indexOf("on") > 0);
> >> }
> >> }
> >> catch (IOException e) { retVal = false;
> >> }
> >> return (retVal);
> >> }
> >>
> >> That might work nicely, until the output of site DIRSTYLE changes
> >> ;)
> >>
> >> >>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen >>>>>
> >>
> >> <sc...@javactivity.org> said:
> >> > Maybe we're wrong to rely exclusively on the SYST command. Jeff,
> >> > since you evidently have admin access to an NT FTP server, maybe
> >>
> >> you > can find a quick way to distinguish between an NT server in
> >> Unix > DIRSTYLE mode and one in NT mode. LIke maybe the header
> >> information > uses different text or something.
> >>
> >> > Maybe we could have something like this:
> >> >
> >> > if "Windows" == syst() result { // do a list command just to look
> >>
> >> at > the header if header is unix style return unix else return
> >> windows.
> >>
> >> > }
> >> >
> >> > If not, we can always go the FAQ route.
> >> >
> >> > Steve
> >> >
> >> > On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
> >> >> Here on a Windows2003 server toggling the DIRSTYLE doesn't
> >>
> >> change >> the output of the SYS command. It still reports Windows
> >> NT 5.0, so >> if the MSDOS dirstyle is off, then the wrong parser
> >> will get >> autoselected. I guess we could put this in the FAQ or
> >> something >> with some examples maybe.
> >>
> >> >> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen >>>>>
> >> >>
> >> >> <sc...@javactivity.org> said: >> > I think you may be referring
> >>
> >> to something said by a user last
> >>
> >> >> week, > in which he "solved" the problem by configuring his NT
> >>
> >> FTP >> server to > use the "Unix display format". I didn't know
> >> before >> that that was > an option. What I still don't know is if
> >> one takes >> that option, > does the SYST command return "Windows"
> >> or "Unix"? >> If it's the > former, then we have a problem. It's
> >> not an >> unsolvable problem > because you can always use the form
> >> of >> listFiles() that takes a > parser class name or a different
> >> SYST >> value (e.g. listFiles("UNIX") > ) as a parameter, although
> >> you >> can't at present do this from Ant. > (But adding this
> >> capability >> to Ant is what I'm striving towards.)
> >>
> >> >> > A little investigation would be good here. But we need to
> >> >>
> >> >> remember > the point of autodetection. It's not foolproof,
> >>
> >> can't >> be foolproof, > since it depends on SYST identification
> >> which is >> not necessarily > cast in stone. It is an attempt to
> >> raise the >> default success rate > of using listFiles() out of the
> >> box from >> maybe 90% to 98%, by > autodetecting other cases, the
> >> most common >> of which is Windows but > also OS2, VMS, OS400, etc.
> >> So while we >> need to strive to become as > good as possible, I
> >> don't think we'll >> ever hit 100%. FTP is too > loosely specced
> >> for that to happen.
> >>
> >> >> > Default falling back to unix if other methods fail would
> >>
> >> involve
> >>
> >> >> a > much more complex mechanism in which the program would have
> >>
> >> to
> >>
> >> >> > decide ("this isn't working") and try something else. While I
> >> >>
> >> >> wouldn't totally rule that out, I don't at present feel there is
> >> >>
> >> > >> enough solid information to justify that effort.
> >> > >>
> >> >> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
> >> >> >> +1
> >> >> >>
> >> >> >> >2. Autodetection of system type - a BIG feature for the Ant
> >> >>
> >> >> user >> > community and others. We missed the last Ant release
> >>
> >> and >> I'd
> >>
> >> >> >> like not to > miss another.
> >> >> >>
> >> >> >> There is a littly thing whe should try to enhance in the
> >>
> >> future. >> >> Using "Windows" for the NTFTPEntryParser is too
> >> strict as it
> >>
> >> >> might >> depend on a "directory listing format" which is >>
> >>
> >> configureable. >> Maybe a automatic fallback to UnixFTPEntryParser
> >>
> >> >> might help here?
> >> >>
> >> >> >> -- Mario
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> >> To unsubscribe, e-mail:
> >> >>
> >> >> commons-dev-unsubscribe@jakarta.apache.org >> For additional >>
> >>
> >> commands, e-mail: >> commons-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail:
> >> >>
> >> >> commons-dev-unsubscribe@jakarta.apache.org > For additional >>
> >>
> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > To unsubscribe, e-mail:
> >>
> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release
Commons-Net 1.2)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
>Wow, that's nasty. Or maybe not.
>
>
I think using DIRSTYLE to toggle the output isnt that nice.
Another idea could be to change the DefaultFTPEntryParserFactory to
allow easier derivation..
---snip---
public FTPFileEntryParser createFileEntryParser(String key)
{
Class parserClass = null;
try {
parserClass = Class.forName(key);
return (FTPFileEntryParser) parserClass.newInstance();
} catch (ClassNotFoundException e) {
String ukey = null;
if (null != key) {
ukey = key.toUpperCase();
}
if (ukey.indexOf("UNIX") >= 0) {
return createUnixFTPEntryParser();
} else if (ukey.indexOf("VMS") >= 0) {
return createVMSVersioningFTPEntryParser();
} else if (ukey.indexOf("WINDOWS") >= 0) {
return createNTFTPEntryParser();
} else if (ukey.indexOf("OS/2") >= 0) {
return createOS2FTPEntryParser();
} else if (ukey.indexOf("OS/400") >= 0) {
return createOS400FTPEntryParser();
} else {
throw new ParserInitializationException(
"Unknown parser type: " + key);
}
} catch (ClassCastException e) {
throw new ParserInitializationException(
parserClass.getName()
+ " does not implement the interface "
+ "org.apache.commons.net.ftp.FTPFileEntryParser.", e);
} catch (Throwable e) {
throw new ParserInitializationException(
"Error initializing parser", e);
}
}
public FTPFileEntryParser createUnixFTPEntryParser()
{
return new UnixFTPEntryParser();
}
public FTPFileEntryParser createVMSVersioningFTPEntryParser()
{
return new VMSVersioningFTPEntryParser();
}
public FTPFileEntryParser createNTFTPEntryParser()
{
return new NTFTPEntryParser();
}
public FTPFileEntryParser createOS2FTPEntryParser()
{
return new OS2FTPEntryParser();
}
public FTPFileEntryParser createOS400FTPEntryParser()
{
return new OS400FTPEntryParser();
}
---snip---
That way, you still have the current behaviour, and one could easily
override the function "createNTFTPEntryParser()" to return an
UnixFTPEntryParser.
People (including me) deriving from DefaultFTPEntryParserFactory also
benefit from later added parsers.
Ciao,
Mario
Re: [net] NT FTP Server & DIRSTYLE
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
>>>>> On Wed, 31 Mar 2004 22:22:24 -0600, Steve Cohen <sc...@javactivity.org> said:
> Wow, that's nasty. Or maybe not. It sounds like there is a default
> admin setting you can make and then the site DIRSTYLE command
> toggles the feature on and off for the duration of the connection,
> right?
Yes, it only effects your connection. Since each time you call 'site
dirstyle' it toggles, in the original code snippet I was calling 'site
dirstyle' twice, just to determine what the current setting is, *not*
change it ( although it is changed for a short while ). You are
correct and the administrator can have a site default to either Unix
or MSDOS style listings. We are currently using this method and
haven't had trouble.
> I see several ways we could go.
> 1. Just leave it as it is. (safest?)
> 2. try your test (if SYST returns "Windows") and then pick the
> appropriate parser.
> 3. If SYST returns Windows, run the site DIRSTYLE command once
> or twice as needed to force the session into UNIX mode and
use the Unix parser.
> 4. If SYST returns Windows, run the site DIRSTYLE command once or
> twice as needed to force the session into Windows mode and use
> the NT parser.
I vote 2.
> I am assuming that calling the DIRSTYLE command is only for that
> session, right? Do all versions of NT (4.0, 2K, XP, etc.) support
> this command?
I've seen this dirstyle setting on all Microsoft Windows FTP servers
I've come across so far.
> What is your recommendation? I think we should take your
> recommendation here as you seem to have the most knowledge. It
> sounds like we could get such a change in and not delay the release
> if you are willing to test this in action. Does that make sense -
> or should we just leave it alone for now.
I think we ( [net] ) shouldn't switch the users current dirstyle on
them. Lets use this method to determine what the current dirstyle is
and then give the user the correct parser. We never want the inquiry
to blow up, so we should default to NT's Parser. I'll test and/or
write up an additional test for our functional suite.
> What I am trying to avoid is causing trouble for our poor user last
> week who just "solved" the problem using our earlier version by
> switching to unix mode on his server, and will now be broken by our
> fix.
We ( at work ) are currently using 'site dirstyle' in some cases to
programmatically force the site to unix listings ( your solution 3 )
in order to use the original list parsers ( yea, we still have some
old stuff using the old parsers! ).
> On Wednesday 31 March 2004 1:05 pm, Jeffrey D. Brekke wrote:
>> The only way we've found is to use the output of the SITE DIRSTYLE
>> command itself, calling it twice:
>>
ftp> site DIRSTYLE
>> 200 MSDOS-like directory output is off
ftp> site DIRSTYLE
>> 200 MSDOS-like directory output is on
>>
>> Then parse that last line:
>>
>> /** * Method isMSDOSDirstyle. * @return String */ public boolean
>> isMSDOSDirstyle() { boolean retVal = false; try { if
>> (sendSiteCommand("DIRSTYLE")) { sendSiteCommand("DIRSTYLE"); retVal
>> = (getReplyString().indexOf("on") > 0);
>> }
>> }
>> catch (IOException e) { retVal = false;
>> }
>> return (retVal);
>> }
>>
>> That might work nicely, until the output of site DIRSTYLE changes
>> ;)
>>
>> >>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen >>>>>
>> <sc...@javactivity.org> said:
>> >
>> > Maybe we're wrong to rely exclusively on the SYST command. Jeff,
>> > since you evidently have admin access to an NT FTP server, maybe
>> you > can find a quick way to distinguish between an NT server in
>> Unix > DIRSTYLE mode and one in NT mode. LIke maybe the header
>> information > uses different text or something.
>> >
>> > Maybe we could have something like this:
>> >
>> > if "Windows" == syst() result { // do a list command just to look
>> at > the header if header is unix style return unix else return
>> windows.
>> > }
>> >
>> > If not, we can always go the FAQ route.
>> >
>> > Steve
>> >
>> > On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
>> >> Here on a Windows2003 server toggling the DIRSTYLE doesn't
>> change >> the output of the SYS command. It still reports Windows
>> NT 5.0, so >> if the MSDOS dirstyle is off, then the wrong parser
>> will get >> autoselected. I guess we could put this in the FAQ or
>> something >> with some examples maybe.
>> >>
>> >> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen >>>>>
>> >>
>> >> <sc...@javactivity.org> said: >> > I think you may be referring
>> to something said by a user last
>> >>
>> >> week, > in which he "solved" the problem by configuring his NT
>> FTP >> server to > use the "Unix display format". I didn't know
>> before >> that that was > an option. What I still don't know is if
>> one takes >> that option, > does the SYST command return "Windows"
>> or "Unix"? >> If it's the > former, then we have a problem. It's
>> not an >> unsolvable problem > because you can always use the form
>> of >> listFiles() that takes a > parser class name or a different
>> SYST >> value (e.g. listFiles("UNIX") > ) as a parameter, although
>> you >> can't at present do this from Ant. > (But adding this
>> capability >> to Ant is what I'm striving towards.)
>> >>
>> >> > A little investigation would be good here. But we need to
>> >>
>> >> remember > the point of autodetection. It's not foolproof,
>> can't >> be foolproof, > since it depends on SYST identification
>> which is >> not necessarily > cast in stone. It is an attempt to
>> raise the >> default success rate > of using listFiles() out of the
>> box from >> maybe 90% to 98%, by > autodetecting other cases, the
>> most common >> of which is Windows but > also OS2, VMS, OS400, etc.
>> So while we >> need to strive to become as > good as possible, I
>> don't think we'll >> ever hit 100%. FTP is too > loosely specced
>> for that to happen.
>> >>
>> >> > Default falling back to unix if other methods fail would
>> involve
>> >>
>> >> a > much more complex mechanism in which the program would have
>> to
>> >>
>> >> > decide ("this isn't working") and try something else. While I
>> >
>> >>
>> >> wouldn't totally rule that out, I don't at present feel there is
>> > >> enough solid information to justify that effort.
>> >>
>> >> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
>> >> >> +1
>> >> >>
>> >> >> >2. Autodetection of system type - a BIG feature for the Ant
>> >>
>> >> user >> > community and others. We missed the last Ant release
>> and >> I'd
>> >>
>> >> >> like not to > miss another.
>> >> >>
>> >> >> There is a littly thing whe should try to enhance in the
>> future. >> >> Using "Windows" for the NTFTPEntryParser is too
>> strict as it
>> >>
>> >> might >> depend on a "directory listing format" which is >>
>> configureable. >> Maybe a automatic fallback to UnixFTPEntryParser
>> >> might help here?
>> >>
>> >> >> -- Mario
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> >> To unsubscribe, e-mail:
>> >>
>> >> commons-dev-unsubscribe@jakarta.apache.org >> For additional >>
>> commands, e-mail: >> commons-dev-help@jakarta.apache.org
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >>
>> >> > To unsubscribe, e-mail:
>> >>
>> >> commons-dev-unsubscribe@jakarta.apache.org > For additional >>
>> commands, e-mail: commons-dev-help@jakarta.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> commands, e-mail: commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release Commons-Net 1.2)
Posted by Steve Cohen <sc...@javactivity.org>.
Wow, that's nasty. Or maybe not.
It sounds like there is a default admin setting you can make and then the site
DIRSTYLE command toggles the feature on and off for the duration of the
connection, right?
I see several ways we could go.
1. Just leave it as it is. (safest?)
2. try your test (if SYST returns "Windows") and then pick the appropriate
parser.
3. If SYST returns Windows, run the site DIRSTYLE command once or twice as
needed to force the session into UNIX mode and use the Unix parser.
4. If SYST returns Windows, run the site DIRSTYLE command once or twice as
needed to force the session into Windows mode and use the NT parser.
I am assuming that calling the DIRSTYLE command is only for that session,
right? Do all versions of NT (4.0, 2K, XP, etc.) support this command?
What is your recommendation? I think we should take your recommendation here
as you seem to have the most knowledge. It sounds like we could get such a
change in and not delay the release if you are willing to test this in
action. Does that make sense - or should we just leave it alone for now.
What I am trying to avoid is causing trouble for our poor user last week who
just "solved" the problem using our earlier version by switching to unix mode
on his server, and will now be broken by our fix.
Steve
On Wednesday 31 March 2004 1:05 pm, Jeffrey D. Brekke wrote:
> The only way we've found is to use the output of the SITE DIRSTYLE
> command itself, calling it twice:
>
> ftp> site DIRSTYLE
> 200 MSDOS-like directory output is off
> ftp> site DIRSTYLE
> 200 MSDOS-like directory output is on
>
> Then parse that last line:
>
> /**
> * Method isMSDOSDirstyle.
> * @return String
> */
> public boolean isMSDOSDirstyle()
> {
> boolean retVal = false;
> try
> {
> if (sendSiteCommand("DIRSTYLE"))
> {
> sendSiteCommand("DIRSTYLE");
> retVal = (getReplyString().indexOf("on") > 0);
> }
> }
> catch (IOException e)
> {
> retVal = false;
> }
> return (retVal);
> }
>
> That might work nicely, until the output of site DIRSTYLE changes ;)
>
> >>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > Maybe we're wrong to rely exclusively on the SYST command. Jeff,
> > since you evidently have admin access to an NT FTP server, maybe you
> > can find a quick way to distinguish between an NT server in Unix
> > DIRSTYLE mode and one in NT mode. LIke maybe the header information
> > uses different text or something.
> >
> > Maybe we could have something like this:
> >
> > if "Windows" == syst() result { // do a list command just to look at
> > the header if header is unix style return unix else return windows.
> > }
> >
> > If not, we can always go the FAQ route.
> >
> > Steve
> >
> > On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
> >> Here on a Windows2003 server toggling the DIRSTYLE doesn't change
> >> the output of the SYS command. It still reports Windows NT 5.0, so
> >> if the MSDOS dirstyle is off, then the wrong parser will get
> >> autoselected. I guess we could put this in the FAQ or something
> >> with some examples maybe.
> >>
> >> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen >>>>>
> >>
> >> <sc...@javactivity.org> said:
> >> > I think you may be referring to something said by a user last
> >>
> >> week, > in which he "solved" the problem by configuring his NT FTP
> >> server to > use the "Unix display format". I didn't know before
> >> that that was > an option. What I still don't know is if one takes
> >> that option, > does the SYST command return "Windows" or "Unix"?
> >> If it's the > former, then we have a problem. It's not an
> >> unsolvable problem > because you can always use the form of
> >> listFiles() that takes a > parser class name or a different SYST
> >> value (e.g. listFiles("UNIX") > ) as a parameter, although you
> >> can't at present do this from Ant. > (But adding this capability
> >> to Ant is what I'm striving towards.)
> >>
> >> > A little investigation would be good here. But we need to
> >>
> >> remember > the point of autodetection. It's not foolproof, can't
> >> be foolproof, > since it depends on SYST identification which is
> >> not necessarily > cast in stone. It is an attempt to raise the
> >> default success rate > of using listFiles() out of the box from
> >> maybe 90% to 98%, by > autodetecting other cases, the most common
> >> of which is Windows but > also OS2, VMS, OS400, etc. So while we
> >> need to strive to become as > good as possible, I don't think we'll
> >> ever hit 100%. FTP is too > loosely specced for that to happen.
> >>
> >> > Default falling back to unix if other methods fail would involve
> >>
> >> a > much more complex mechanism in which the program would have to
> >>
> >> > decide ("this isn't working") and try something else. While I >
> >>
> >> wouldn't totally rule that out, I don't at present feel there is >
> >> enough solid information to justify that effort.
> >>
> >> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
> >> >> +1
> >> >>
> >> >> >2. Autodetection of system type - a BIG feature for the Ant
> >>
> >> user >> > community and others. We missed the last Ant release and
> >> I'd
> >>
> >> >> like not to > miss another.
> >> >>
> >> >> There is a littly thing whe should try to enhance in the future.
> >> >> Using "Windows" for the NTFTPEntryParser is too strict as it
> >>
> >> might >> depend on a "directory listing format" which is
> >> configureable. >> Maybe a automatic fallback to UnixFTPEntryParser
> >> might help here?
> >>
> >> >> -- Mario
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> To unsubscribe, e-mail:
> >>
> >> commons-dev-unsubscribe@jakarta.apache.org >> For additional
> >> commands, e-mail: >> commons-dev-help@jakarta.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > To unsubscribe, e-mail:
> >>
> >> commons-dev-unsubscribe@jakarta.apache.org > For additional
> >> commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[net] NT FTP Server & DIRSTYLE (was Re: [net] [vote] Release
Commons-Net 1.2)
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
The only way we've found is to use the output of the SITE DIRSTYLE
command itself, calling it twice:
ftp> site DIRSTYLE
200 MSDOS-like directory output is off
ftp> site DIRSTYLE
200 MSDOS-like directory output is on
Then parse that last line:
/**
* Method isMSDOSDirstyle.
* @return String
*/
public boolean isMSDOSDirstyle()
{
boolean retVal = false;
try
{
if (sendSiteCommand("DIRSTYLE"))
{
sendSiteCommand("DIRSTYLE");
retVal = (getReplyString().indexOf("on") > 0);
}
}
catch (IOException e)
{
retVal = false;
}
return (retVal);
}
That might work nicely, until the output of site DIRSTYLE changes ;)
>>>>> On Tue, 30 Mar 2004 20:05:33 -0600, Steve Cohen <sc...@javactivity.org> said:
> Maybe we're wrong to rely exclusively on the SYST command. Jeff,
> since you evidently have admin access to an NT FTP server, maybe you
> can find a quick way to distinguish between an NT server in Unix
> DIRSTYLE mode and one in NT mode. LIke maybe the header information
> uses different text or something.
> Maybe we could have something like this:
> if "Windows" == syst() result { // do a list command just to look at
> the header if header is unix style return unix else return windows.
> }
> If not, we can always go the FAQ route.
> Steve
> On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
>> Here on a Windows2003 server toggling the DIRSTYLE doesn't change
>> the output of the SYS command. It still reports Windows NT 5.0, so
>> if the MSDOS dirstyle is off, then the wrong parser will get
>> autoselected. I guess we could put this in the FAQ or something
>> with some examples maybe.
>>
>> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen >>>>>
>> <sc...@javactivity.org> said:
>> >
>> > I think you may be referring to something said by a user last
>> week, > in which he "solved" the problem by configuring his NT FTP
>> server to > use the "Unix display format". I didn't know before
>> that that was > an option. What I still don't know is if one takes
>> that option, > does the SYST command return "Windows" or "Unix"?
>> If it's the > former, then we have a problem. It's not an
>> unsolvable problem > because you can always use the form of
>> listFiles() that takes a > parser class name or a different SYST
>> value (e.g. listFiles("UNIX") > ) as a parameter, although you
>> can't at present do this from Ant. > (But adding this capability
>> to Ant is what I'm striving towards.)
>> >
>> > A little investigation would be good here. But we need to
>> remember > the point of autodetection. It's not foolproof, can't
>> be foolproof, > since it depends on SYST identification which is
>> not necessarily > cast in stone. It is an attempt to raise the
>> default success rate > of using listFiles() out of the box from
>> maybe 90% to 98%, by > autodetecting other cases, the most common
>> of which is Windows but > also OS2, VMS, OS400, etc. So while we
>> need to strive to become as > good as possible, I don't think we'll
>> ever hit 100%. FTP is too > loosely specced for that to happen.
>> >
>> > Default falling back to unix if other methods fail would involve
>> a > much more complex mechanism in which the program would have to
>> > decide ("this isn't working") and try something else. While I >
>> wouldn't totally rule that out, I don't at present feel there is >
>> enough solid information to justify that effort.
>> >
>> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
>> >> +1
>> >>
>> >> >2. Autodetection of system type - a BIG feature for the Ant
>> user >> > community and others. We missed the last Ant release and
>> I'd
>> >>
>> >> like not to > miss another.
>> >>
>> >> There is a littly thing whe should try to enhance in the future.
>> >> Using "Windows" for the NTFTPEntryParser is too strict as it
>> might >> depend on a "directory listing format" which is
>> configureable. >> Maybe a automatic fallback to UnixFTPEntryParser
>> might help here?
>> >>
>> >>
>> >> -- Mario
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org >> For additional
>> commands, e-mail: >> commons-dev-help@jakarta.apache.org
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> commons-dev-unsubscribe@jakarta.apache.org > For additional
>> commands, e-mail: commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] [vote] Release Commons-Net 1.2
Posted by Steve Cohen <sc...@javactivity.org>.
Maybe we're wrong to rely exclusively on the SYST command. Jeff, since you
evidently have admin access to an NT FTP server, maybe you can find a quick
way to distinguish between an NT server in Unix DIRSTYLE mode and one in NT
mode. LIke maybe the header information uses different text or something.
Maybe we could have something like this:
if "Windows" == syst() result {
// do a list command just to look at the header
if header is unix style return unix
else return windows.
}
If not, we can always go the FAQ route.
Steve
On Monday 29 March 2004 12:08 pm, Jeffrey D. Brekke wrote:
> Here on a Windows2003 server toggling the DIRSTYLE doesn't change the
> output of the SYS command. It still reports Windows NT 5.0, so if the
> MSDOS dirstyle is off, then the wrong parser will get autoselected. I
> guess we could put this in the FAQ or something with some examples
> maybe.
>
> >>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen
> >>>>> <sc...@javactivity.org> said:
> >
> > I think you may be referring to something said by a user last week,
> > in which he "solved" the problem by configuring his NT FTP server to
> > use the "Unix display format". I didn't know before that that was
> > an option. What I still don't know is if one takes that option,
> > does the SYST command return "Windows" or "Unix"? If it's the
> > former, then we have a problem. It's not an unsolvable problem
> > because you can always use the form of listFiles() that takes a
> > parser class name or a different SYST value (e.g. listFiles("UNIX")
> > ) as a parameter, although you can't at present do this from Ant.
> > (But adding this capability to Ant is what I'm striving towards.)
> >
> > A little investigation would be good here. But we need to remember
> > the point of autodetection. It's not foolproof, can't be foolproof,
> > since it depends on SYST identification which is not necessarily
> > cast in stone. It is an attempt to raise the default success rate
> > of using listFiles() out of the box from maybe 90% to 98%, by
> > autodetecting other cases, the most common of which is Windows but
> > also OS2, VMS, OS400, etc. So while we need to strive to become as
> > good as possible, I don't think we'll ever hit 100%. FTP is too
> > loosely specced for that to happen.
> >
> > Default falling back to unix if other methods fail would involve a
> > much more complex mechanism in which the program would have to
> > decide ("this isn't working") and try something else. While I
> > wouldn't totally rule that out, I don't at present feel there is
> > enough solid information to justify that effort.
> >
> > On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
> >> +1
> >>
> >> >2. Autodetection of system type - a BIG feature for the Ant user
> >> > community and others. We missed the last Ant release and I'd
> >>
> >> like not to > miss another.
> >>
> >> There is a littly thing whe should try to enhance in the future.
> >> Using "Windows" for the NTFTPEntryParser is too strict as it might
> >> depend on a "directory listing format" which is configureable.
> >> Maybe a automatic fallback to UnixFTPEntryParser might help here?
> >>
> >>
> >> -- Mario
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] [vote] Release Commons-Net 1.2
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Here on a Windows2003 server toggling the DIRSTYLE doesn't change the
output of the SYS command. It still reports Windows NT 5.0, so if the
MSDOS dirstyle is off, then the wrong parser will get autoselected. I
guess we could put this in the FAQ or something with some examples
maybe.
>>>>> On Mon, 29 Mar 2004 06:47:25 -0600, Steve Cohen <sc...@javactivity.org> said:
> I think you may be referring to something said by a user last week,
> in which he "solved" the problem by configuring his NT FTP server to
> use the "Unix display format". I didn't know before that that was
> an option. What I still don't know is if one takes that option,
> does the SYST command return "Windows" or "Unix"? If it's the
> former, then we have a problem. It's not an unsolvable problem
> because you can always use the form of listFiles() that takes a
> parser class name or a different SYST value (e.g. listFiles("UNIX")
> ) as a parameter, although you can't at present do this from Ant.
> (But adding this capability to Ant is what I'm striving towards.)
> A little investigation would be good here. But we need to remember
> the point of autodetection. It's not foolproof, can't be foolproof,
> since it depends on SYST identification which is not necessarily
> cast in stone. It is an attempt to raise the default success rate
> of using listFiles() out of the box from maybe 90% to 98%, by
> autodetecting other cases, the most common of which is Windows but
> also OS2, VMS, OS400, etc. So while we need to strive to become as
> good as possible, I don't think we'll ever hit 100%. FTP is too
> loosely specced for that to happen.
> Default falling back to unix if other methods fail would involve a
> much more complex mechanism in which the program would have to
> decide ("this isn't working") and try something else. While I
> wouldn't totally rule that out, I don't at present feel there is
> enough solid information to justify that effort.
> On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
>> +1
>>
>> >2. Autodetection of system type - a BIG feature for the Ant user
>> > community and others. We missed the last Ant release and I'd
>> like not to > miss another.
>>
>> There is a littly thing whe should try to enhance in the future.
>> Using "Windows" for the NTFTPEntryParser is too strict as it might
>> depend on a "directory listing format" which is configureable.
>> Maybe a automatic fallback to UnixFTPEntryParser might help here?
>>
>>
>> -- Mario
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] [vote] Release Commons-Net 1.2
Posted by Mario Ivankovits <ma...@ops.co.at>.
Steve Cohen wrote:
>It is an
>attempt to raise the default success rate of using listFiles() out of the box
>from maybe 90% to 98%, by autodetecting other cases,
>
...
>I don't think we'll ever hit 100%. FTP is too
>loosely specced for that to happen.
>
>
I am complete with you. And i know, that it cant be 100% perfect at any
time.
I will see if i can find an IIS to have a look at it.
I just think that this kind of server is in use, and maybe not too less
- not everyone might easily change this flag.
If it is not possible to decide this by SYST (as i said, i will have a
look at it), than the fallback to Unix should be handeled directly
within the NT Parser (if match() else ....) - i dont meant to implement
a generic fallback.
-- Mario
Re: [net] [vote] Release Commons-Net 1.2
Posted by Steve Cohen <sc...@javactivity.org>.
I think you may be referring to something said by a user last week, in which
he "solved" the problem by configuring his NT FTP server to use the "Unix
display format". I didn't know before that that was an option. What I still
don't know is if one takes that option, does the SYST command return
"Windows" or "Unix"? If it's the former, then we have a problem. It's not
an unsolvable problem because you can always use the form of listFiles() that
takes a parser class name or a different SYST value (e.g. listFiles("UNIX") )
as a parameter, although you can't at present do this from Ant. (But adding
this capability to Ant is what I'm striving towards.)
A little investigation would be good here. But we need to remember the point
of autodetection. It's not foolproof, can't be foolproof, since it depends
on SYST identification which is not necessarily cast in stone. It is an
attempt to raise the default success rate of using listFiles() out of the box
from maybe 90% to 98%, by autodetecting other cases, the most common of which
is Windows but also OS2, VMS, OS400, etc. So while we need to strive to
become as good as possible, I don't think we'll ever hit 100%. FTP is too
loosely specced for that to happen.
Default falling back to unix if other methods fail would involve a much more
complex mechanism in which the program would have to decide ("this isn't
working") and try something else. While I wouldn't totally rule that out, I
don't at present feel there is enough solid information to justify that
effort.
On Sunday 28 March 2004 11:59 pm, Mario Ivankovits wrote:
> +1
>
> >2. Autodetection of system type - a BIG feature for the Ant user
> > community and others. We missed the last Ant release and I'd like not to
> > miss another.
>
> There is a littly thing whe should try to enhance in the future.
> Using "Windows" for the NTFTPEntryParser is too strict as it might
> depend on a "directory listing format" which is configureable.
> Maybe a automatic fallback to UnixFTPEntryParser might help here?
>
>
> -- Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [net] [vote] Release Commons-Net 1.2
Posted by Mario Ivankovits <ma...@ops.co.at>.
+1
>2. Autodetection of system type - a BIG feature for the Ant user community
>and others. We missed the last Ant release and I'd like not to miss another.
>
>
There is a littly thing whe should try to enhance in the future.
Using "Windows" for the NTFTPEntryParser is too strict as it might
depend on a "directory listing format" which is configureable.
Maybe a automatic fallback to UnixFTPEntryParser might help here?
-- Mario
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org