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
> >>>>> <[EMAIL PROTECTED]> 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 >>>>>
> >>
> >> <[EMAIL PROTECTED]> 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 >>>>>
> >> >>
> >> >> <[EMAIL PROTECTED]> 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:
> >> >>
> >> >> [EMAIL PROTECTED] >> For additional >>
> >>
> >> commands, e-mail: >> [EMAIL PROTECTED]
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> >> > To unsubscribe, e-mail:
> >> >>
> >> >> [EMAIL PROTECTED] > For additional >>
> >>
> >> commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >> ---------------------------------------------------------------------
> >>
> >> > To unsubscribe, e-mail:
> >>
> >> [EMAIL PROTECTED] > For additional
> >> commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
