You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Jeffrey D. Brekke" <jb...@wi.rr.com> on 2004/04/01 16:24:59 UTC
Re: [net] NT FTP Server & DIRSTYLE
>>>>> 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
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