commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <sco...@javactivity.org>
Subject Re: [net] NT FTP Server & DIRSTYLE
Date Sat, 03 Apr 2004 18:48:50 GMT
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


Mime
View raw message