commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jbre...@wi.rr.com (Jeffrey D. Brekke)
Subject Re: [net] NT FTP Server & DIRSTYLE
Date Mon, 05 Apr 2004 05:20:08 GMT

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 <scohen@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 >>>>>
>> <scohen@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 >>>>>
>> >>
>> >> <scohen@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 >>>>>
>> >> >>
>> >> >> <scohen@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
>> >>>>>
>> >> >> >>
>> >> >> >> <scohen@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


Mime
View raw message