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 Sat, 03 Apr 2004 02:18:26 GMT

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

-- 
=====================================================================
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