read ftp:// error

Hi all, i am playing around with ftp and /view 1.2 on a win98-box. I tried to read a file on a HPUX-Server and always get the following error: Script Error: Invalid argument: 29/Mai/2001/4:04 Where: to-date Near: to date! :value Any ideas out there? Thorsten

From: "Thorsten Moeller"

> i am playing around with ftp and /view 1.2 on a win98-box. I tried to

> file on a HPUX-Server and always get the following error: > > Script Error: Invalid argument: 29/Mai/2001/4:04 > Where: to-date > Near: to date! :value > > Any ideas out there?

GS Jones wrote:

> From: "Thorsten Moeller" > My version of REBOL does not recognize the month abbreviation "Mai". Is > this a typo? > "29/Mar/2001/4:04" is correctly made into a date.

Hi Scott, this is no typo, maybe it is depending to the "German"-Version of HPUX 11. I looked into the filesystem and there the month is Mai (german) for May (eng.). Perhaps RT should consider local Versions of OS's. Perhaps there could be a workaround. Thorsten

Can you reveal your codes lines where you are getting the problem? At 01:16 PM 5/29/01 +0200, you wrote:

Thorsten Moeller wrote:

> Perhaps there could be a workaround.

Hi Mike, here is an the Code incl. error-message:

>> print read ftp://user:[pass--192--168--200--10]/home/whc/tsbewout

At 14:03 29.5.2001 +0100, you wrote:

>Thorsten Moeller wrote: >>Perhaps there could be a workaround. >Persuade all of Germany to use May instead of Mai? :)

>Seriously though, you could preprocess the string converting >DD/Mai/YYYY into DD/May/YYYY I suppose.

Hi Joanna, i completely agree with you regarding the implementation of all variations of month names around the world. But, we received our sever preconfiguered from HP. And Users of Applications don't care about what version of OS is running on a server they want to access with an FTP-Client. Why must there be any to-date conversion when i want to read a file via FTP? Thorsten -----Ursprungliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von Joanna Kurki Gesendet: Dienstag, 29. Mai 2001 15:42 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: read ftp:// error At 14:03 29.5.2001 +0100, you wrote:

>Thorsten Moeller wrote: >>Perhaps there could be a workaround. >Persuade all of Germany to use May instead of Mai? :)

>Seriously though, you could preprocess the string converting >DD/Mai/YYYY into DD/May/YYYY I suppose.

Hello Thorsten, Have you tried: probe info? ftp://user:[pass--your-server]/some-path/any-file If not try it...I am curious for the result Regards Cyphre

From: "Thorsten Moeller" ...

> here is an the Code incl. error-message: > > >> print read ftp://user:[pass--192--168--200--10]/home/whc/tsbewout > ** Script Error: Invalid argument: 29/Mai/2001/4:04 > ** Where: to-date > ** Near: to date! :value > > Perhaps i should send this to RT feedback.

At 16:40 29.5.2001 +0200, you wrote:

>Hi Joanna, > >i completely agree with you regarding the implementation of all variations >of month names around the world. But, we received our sever preconfiguered >from HP. And Users of Applications don't care about what version of OS is >running on a server they want to access with an FTP-Client.

>Why must there be any to-date conversion when i want to read a file via FTP?

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

> Hi Mike, > here is an the Code incl. error-message: > ** Near: to date! :value > Perhaps i should send this to RT feedback.

> Thorsten

Hi, thanks for all your postings. I submitted the problem to feedback. If i will get a result i will inform you via this list. Meanwhile i think i have to change something on the server to get this running, maybe the easier and faster way. I hoped that perhaps Holger would give his $0.2, as he his the RT-Expert for this. Thorsten

From: "Thorsten Moeller"

> thanks for all your postings. I submitted the > problem to feedback. If i will get a result i > I hoped that perhaps Holger would give his > $0.2, as he his the RT-Expert for this.

Hi Scott, thanks for your offer. HP`s moth abbreviations wouldn't be the problem, but the server is just internal and running our ERP-System. So, it is not possible to give you even a secure access to it for demonstration. Perhaps you can give me some instructions what to do, or what you have in mind, so i can put it together. Any results can be emailed off-list. Think about it !? Thanks again, Thorsten -----Ursprüngliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von GS Jones Gesendet: Mittwoch, 30. Mai 2001 13:53 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: read ftp:// error From: "Thorsten Moeller"

> thanks for all your postings. I submitted the > problem to feedback. If i will get a result i > I hoped that perhaps Holger would give his > $0.2, as he his the RT-Expert for this.

From: "Thorsten Moeller"

> Hi Scott, > > thanks for your offer. HP`s moth abbreviations wouldn't be the

> the server is just internal and running our ERP-System. So, it is not > possible to give you even a secure access to it for demonstration. > > Perhaps you can give me some instructions what to do, or what you have

> mind, so i can put it together. > Any results can be emailed off-list. > > Think about it !?

Hi Scott, thanks for your detailed explanation what to do. I produced the file, studied its working, and did some modification, mainly for data tracking. But for some purposes, when i "do" the generated file as described, it doesn't seem to have any effect. Is there a way to verify that REBOL uses my scheme, not the standard one? As well REBOL ask me for a header when doing the .../ftp_hack.r, so my file has to look like this REBOL [] FTP: make object! [ scheme: 'FTP host: none port-id: 21 user: none ..... Bringing this task to a success, i will post a workaround to the list. Thorsten -----Ursprüngliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von GS Jones Gesendet: Mittwoch, 30. Mai 2001 16:57 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: read ftp:// error From: "Thorsten Moeller"

> Hi Scott, > > thanks for your offer. HP`s moth abbreviations wouldn't be the

> the server is just internal and running our ERP-System. So, it is not > possible to give you even a secure access to it for demonstration. > > Perhaps you can give me some instructions what to do, or what you have

> mind, so i can put it together. > Any results can be emailed off-list. > > Think about it !?

Hi, Thorsten, My suggestions yesterday clearly suffered from sloppiness. Sorry! I've corrected the oversites AND tested what I could of the result. It should work now. Comments interspersed below: From: "Thorsten Moeller"

> Hi Scott, > > thanks for your detailed explanation what to do. > I produced the file, studied its working, and did > some modification, mainly for data tracking. > But for some purposes, when i "do" the generated > file as described, it doesn't seem to have any effect.

> Is there a way to verify that REBOL uses my > scheme, not the standard one?

> As well REBOL ask me for a header when doing > the .../ftp_hack.r, so my file has to look like this > user: none > .....

> Bringing this task to a success, i will post a > workaround to the list. > > Thorsten

Hi Scott, Tried it out with "Mai" to "May" and works fine for the file i was trying to read. I have to find files for the other months to be tested. Keep you informed via the list. For a more generic use, perhaps there could be a kind of library-file containig the translations even for other languages. This file could be modified by any user out there running into these problems. What do you think? Thorsten -----Ursprüngliche Nachricht----- Von: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]Im Auftrag von GS Jones Gesendet: Donnerstag, 31. Mai 2001 14:19 An: [rebol-list--rebol--com] Betreff: [REBOL] Re: AW: Re: read ftp:// error Hi, Thorsten, My suggestions yesterday clearly suffered from sloppiness. Sorry! I've corrected the oversites AND tested what I could of the result. It should work now. Comments interspersed below: From: "Thorsten Moeller"

> Hi Scott, > > thanks for your detailed explanation what to do. > I produced the file, studied its working, and did > some modification, mainly for data tracking. > But for some purposes, when i "do" the generated > file as described, it doesn't seem to have any effect.

> Is there a way to verify that REBOL uses my > scheme, not the standard one?

> As well REBOL ask me for a header when doing > the .../ftp_hack.r, so my file has to look like this > user: none > .....

> Bringing this task to a success, i will post a > workaround to the list. > > Thorsten

From: "Thorsten Moeller"

> Tried it out with "Mai" to "May" and works fine for the file i was

> read.

> I have to find files for the other months to be tested. > > Keep you informed via the list. > > For a more generic use, perhaps there could be a kind of library-file > containig the translations even for other languages. This file could

> modified by any user out there running into these problems. > > What do you think?

The real issue is of localization which is an issue all to itself and not particularly related to FTP. However, for the purposes of patching your FTP scheme and following the ideas already put forth in this thread, let me suggest the following change. As you have noticed, the problem is that REBOL is reading the directory before the download abd is having trouble parsing the directory information. It does this because it is trying to find out how large the file is before download so that it can download most efficiently... almost all FTP clients do this in order to display a progress bar. Anyhow, here's an added function to convert a month abbreviation to the REBOL readable version and a change to the first line of the add-date function in the FTP protocol. convert-month: func [month [string!] /local conv seek] [ conv: [ "Mai" ["May"] ] if seek: find conv month [return first first find seek block!] month ] add-date: func [] [ month: convert-month first pdate ; these lines reverse the month and day so we can make a date of it ... ... ... ] The conv block in convert-month can be extended to handle any number of languages simply by adding another string before the block containing the result version. For example, if May were also abbreviated as "Moi", and "Mal" in some other languages then conv would have a line like this: Mai "Moi" "Mal" ["May"] The function finds what you have, "Mai" or other abbreviation in the list. If it does find it, it then grabs the element in the first block. This way you can have as many mappings from other languages to the result as you want. If you do compile a list of abbreviations from elsewhere please post them as we might include this type of solution in the next versions. Needless to say, this blowout will be fixed one way or another. Sterling

Hi Scott, Sterling, Scott, i totally agree with your thoughts. Have you looked at Sterling's function? Sterling, thanks a lot for your contribution. I think that this function is the one we can easily use for this purpose, what do you think Scott? Together with your collected abbreviations this will do it. I hope that i can test it tomorrow, back in my company. But there should be a more easy way to do the patching, like a script you only have to add to your user.r Any other ideas? Thorsten

From: <[sterling--rebol--com]>

> The real issue is of localization which is > an issue all to itself and not particularly > most efficiently... almost all FTP clients do > this in order to display a progress bar.

> if seek: find conv month [return first first find seek block!]

> This way you can have as many mappings > from other languages to the result as you want.

> If you do compile a list of abbreviations from elsewhere please post > them as we might include this type of solution in the next versions.

> Needless to say, this blowout will be fixed one way or another.

From: "Thorsten Moeller"

> Scott, i totally agree with your thoughts. Have you > looked at Sterling's function?

> Sterling, thanks a lot for your contribution. > I think that this function is the one we can > easily use for this purpose, what do you think > Scott? Together with your collected abbreviations this > will do it.

> I hope that i can test it tomorrow, back in my company. > But there should be a more easy way to do the patching, > like a script you only have to add to your user.r > > Any other ideas?

Ah yes. Guru tricks not yet in the documentation most likely.

> > if seek: find conv month [return first first find seek block!] > .... > We all new RT would! Thanks for your input, Sterling. > --Scott Jones

Hi Thorsten, Scott, Sterling! Congratulations! Great to see this volleyball-programming in the list :) my $0.02: would work system/schemes/ftp: make system/schemes/ftp[ the-new-functions ] ? if ftp playes clean with contexts, it should work after that. Small enough for the user.r ? -Volker

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

> Ah yes. Guru tricks not yet in the documentation most likely. > > > if seek: find conv month [return first first find seek block!] > with that would then be to have all abbreviations for all languages of > the world in your program and that's ridiculous.

> Sterling

Hi, Thorsten, Sterling, Volker, VN> Great to see this volleyball-programming in the list :) Yes, it takes a hard hit to get the volleyball all the way from central US to central Europe! VN> my $0.02: VN> would work VN> system/schemes/ftp: make system/schemes/ftp[ VN> the-new-functions VN> ] VN> ? This would be a great idea if the critical part were not buried with in a function of a function. VN> if ftp playes clean with contexts, it should work after that. VN> Small enough for the user.r ? This was exactly what I was looking for. I am certain that I am as skilled as you, Volker. You will probably show me a nice short way to do this. What I was wanting to do was to surgically implant a patch in the FTP scheme. It took a lot of peeking, poking and hacking to figure this out, but I believe that I have it. I have looked the world over (OK, maybe only a tiny fraction of the world) for a comprehensive list of month abbreviations. I give up!!!! I have at least assured myself that my earlier list seems OK except that I am still unsure about the June and July issue (Juin and Juillet -> Jui and Jui???). I think I'll just leave it as Sterling left it in his script. Here is the proposed script and patch, with the buglet fixed in the script. ;;;;;;;;; ;Sterling's script convert-month: func [month [string!] /local conv seek] [ conv: [ Ene "Gen" ["Jan"] Fév "Fev" ["Feb"] Mär ["Mar"] Avr "Abr" ["Apr"] Mag "Mai" ["May"] Jui "Giu" ["Jun"] Lug ["Jul"] Aoû "Ago" ["Aug"] Set ["Sep"] Ott "Out" ["Oct"] ; ["Nov"] ; none here Dic "Déc" "Dez" ["Dec"] ] if seek: find conv month [return first first find seek block!] month ] ;Scott's surgical insertion patch tool ;note, this will likely need to be on one line ;changes {month: first pdate} to {month: convert-word first pdate} insert next find pick pick get in system/schemes/ftp/handler 'parse-files 2 31 to-set-word 'month 'convert-month ;;;;;;;; This leaves the 'convert-month script in the global namespace, which would be an benefit if needed elsewhere. I guess it could also be put into the FTP scheme object block. My surgical insertion tool is admittedly fragile in that it is not checking for versions. I started out putting in a version checker, but left it out in the end. If this blowout will be fixed in the next release, then the user would have to specifically remember to remove this patch from the user.r file or risk corrupting the code. Thorsten can check it out, and you are all welcome to comment. --Scott Jones

Hi Scott, I just want to comment on the patching process. I recognise that you made the decision to leave out the check which I respect. But I think it should be highlighted for people that are maybe new to this concept that patches introduce risk of unexpected/unpredictable behaviour if the right set of remote circumstances arise - which is generally considered by pessimists/realists guaranteed to happen :-) So, patches are generally to be avoided unless really required. Also, because of the way we patch Rebol code, old patches are still applied to new versions. This is different to the traditional patch which is applied directly to the old executable and lost when a new version is installed. I had to patch the FTP scheme recently and because I couldn't trust myself to remember the patch, I've put in version checking and a paranoid test to ensure that the patch is changing what it thinks it is changing. You can have a look at if it is of interest. It doesn't handle the user-unaffected-by-bug-case though. http://www.codeconscious.com/rebol-library/patches.r Regards, Brett. ----- Original Message ----- From: "GS Jones" <[gjones05--mail--orion--org]> To: <[rebol-list--rebol--com]> Sent: Friday, June 01, 2001 1:01 PM Subject: [REBOL] Re: read ftp:// error Hi, Thorsten, Sterling, Volker, VN> Great to see this volleyball-programming in the list :) Yes, it takes a hard hit to get the volleyball all the way from central US to central Europe! VN> my $0.02: VN> would work VN> system/schemes/ftp: make system/schemes/ftp[ VN> the-new-functions VN> ] VN> ? This would be a great idea if the critical part were not buried with in a function of a function. VN> if ftp playes clean with contexts, it should work after that. VN> Small enough for the user.r ? This was exactly what I was looking for. I am certain that I am as skilled as you, Volker. You will probably show me a nice short way to do this. What I was wanting to do was to surgically implant a patch in the FTP scheme. It took a lot of peeking, poking and hacking to figure this out, but I believe that I have it. I have looked the world over (OK, maybe only a tiny fraction of the world) for a comprehensive list of month abbreviations. I give up!!!! I have at least assured myself that my earlier list seems OK except that I am still unsure about the June and July issue (Juin and Juillet -> Jui and Jui???). I think I'll just leave it as Sterling left it in his script. Here is the proposed script and patch, with the buglet fixed in the script. ;;;;;;;;; ;Sterling's script convert-month: func [month [string!] /local conv seek] [ conv: [ Ene "Gen" ["Jan"] Fév "Fev" ["Feb"] Mär ["Mar"] Avr "Abr" ["Apr"] Mag "Mai" ["May"] Jui "Giu" ["Jun"] Lug ["Jul"] Aoû "Ago" ["Aug"] Set ["Sep"] Ott "Out" ["Oct"] ; ["Nov"] ; none here Dic "Déc" "Dez" ["Dec"] ] if seek: find conv month [return first first find seek block!] month ] ;Scott's surgical insertion patch tool ;note, this will likely need to be on one line ;changes {month: first pdate} to {month: convert-word first pdate} insert next find pick pick get in system/schemes/ftp/handler 'parse-files 2 31 to-set-word 'month 'convert-month ;;;;;;;; This leaves the 'convert-month script in the global namespace, which would be an benefit if needed elsewhere. I guess it could also be put into the FTP scheme object block. My surgical insertion tool is admittedly fragile in that it is not checking for versions. I started out putting in a version checker, but left it out in the end. If this blowout will be fixed in the next release, then the user would have to specifically remember to remove this patch from the user.r file or risk corrupting the code. Thorsten can check it out, and you are all welcome to comment. --Scott Jones

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

> Hi, Thorsten, Sterling, Volker, > VN> Great to see this volleyball-programming in the list :) > Yes, it takes a hard hit to get the volleyball all the way from

> US to central Europe!

> VN> my $0.02: > VN> would work > VN> ? > This would be a great idea if the critical part were not buried with

> a function of a function. > VN> if ftp playes clean with contexts, it should work after that. > VN> Small enough for the user.r ? > This was exactly what I was looking for. I am certain that I am as > skilled as you, Volker. You will probably show me a nice short way to > do this.

> What I was wanting to do was to surgically implant a patch in the FTP > scheme. It took a lot of peeking, poking and hacking to figure this > out, but I believe that I have it. > I have looked the world over (OK, maybe only a tiny fraction of the > world) for a comprehensive list of month abbreviations. I give up!!!! > I have at least assured myself that my earlier list seems OK except

> I am still unsure about the June and July issue (Juin and Juillet -> Jui > and Jui???). I think I'll just leave it as Sterling left it in his > insert next find pick pick get in system/schemes/ftp/handler > 'parse-files 2 31 to-set-word 'month 'convert-month

> ;;;;;;;; > This leaves the 'convert-month script in the global namespace, which > out putting in a version checker, but left it out in the end. If this > "blowout" will be fixed in the next release, then the user would have

> specifically remember to remove this patch from the user.r file or

> corrupting the code.

> Thorsten can check it out, and you are all welcome to comment. > --Scott Jones

Hi Scott, Sterling, the only thing i can say is WELL DONE, works great. Just inserted your script into my user.r and off we go, without any problems. I kept my self informed that i am using a patched version of REBOL with adding print "" print {"++++++++++++++++++++++++++++++++++++++++++++++++++++ ATTENTION - ATTENTION - ATTENTION - ATTENTION + Your ftp-scheme has been patched to suite international abbreviations. + Please remove this patch from your user.r if you upgrade to a higher + Version in which the problem is fixed by REBOL-Technologies!! + ATTENTION - ATTENTION - ATTENTION - ATTENTION + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++"} print "" print "" after your script. It is enough for me cause i am mainly working on the console. For apps running in quiet mode this won't be enough. Disabling the patching by Version verification could be a problem as we don't know the next Version numbers and if the Problem will be fixed in this Release. So, the earliest date we can make the patching related to Versions is when these Versions are out and we could be sure that the problem is fixed. Do you have any other suggestions? Thorsten

Hi, Thorsten, Sterling, Volker, Brett, This volleyball game now spans the globe. Brett, you are really going to have to hit the ball hard from "Down Under" BH> I just want to comment on the patching process. BH> I recognise that you made the decision to leave BH> out the check which I respect. ... Brett, thank you for being so diplomatic. My decision for this final beta was based more on fatique than anything else. I've not messed with version checking before, so when I started setting up the different product and version checks, I realized that it was going to get involved. I wanted to get the script-patch posted so that Thorsten could give it a test drive in his morning. BH> But I think it should be highlighted for people that BH> are maybe new to this concept that patches BH> introduce risk of unexpected/unpredictable BH> behaviour if the right set of remote circumstances BH> arise - which is generally considered by BH> pessimists/realists guaranteed to happen :-) I absolutely agree that before this is submitted to some "patch library" (is there such a beast?), the product-version checking is a better idea. You've set up a nice framework in the patches.r file. I'm trying to grok the content (like using 'use); lot's to learn, but Thorsten's theorem and Brett's bric-a-brac and Volker's volleys and Sterling's stuff are giving me lots of good material. Thanks. (I was struggling with the rhymes, as is probably obvious.) VN> Sorry. I thought you used full source for better patching. VN> it was Thorsten who asked for a shorter version. Yes, we were hacking on the full source; it is easier for lead-poisoned people like me to see what I am doing. Originally I envisoned leaving the hacked scheme as a separate file, like I did with the ESMTP version of SMTP. But I realized that since "all the code is just data", that there's got to be a way to poke the part need into the code. I highly suspected that someone had done this before, but I couldn't remember seeing it on the list nor on all the sites that I have viewed. Again, fatique kept me from doing another search, so I started kacking and came up with my one liner. VN> Of course i should wait for you to tell, VN> but there was the ball, quick coming, iam VN> standing ready.. ;-) Yes, those "spiked balls" come fast. VN> Playing with the parts of my swiss-knife, for the nice part: VN> VN> p: second get in system/schemes/ftp/handler 'parse-files VN> p: first find/tail p [add-date: func[]] VN> insert next p [convert-month] VN> ? p Your version (and Brett's) is infinitely easier to read (OK, maybe not inifinitely; just more like 1/0.0000000001; I'm prone to exageration sometimes ;-). There is no doubt about it, I've got to get me a Swiss knife just like yours!!! SJ> My surgical insertion tool is admittedly fragile in that it is SJ> not checking for versions. I started out putting in a version SJ> checker, but left it out in the end. If this "blowout" will be SJ> fixed in the next release, then the user would have to SJ> specifically remember to remove this patch from the user.r SJ> file or risk corrupting the code. VN> The saw and the screwdriver and the - ah here: VN> v: system/version VN> v/4: v/5: 0 VN> if 1.2.0 <> v [request/confirm "BANG?"] VN> ;write/append %hidden-patches-log "i patched ftp-scheme!!" Got to get me one of those knives! Here was the framework that I put together: if either system/view [ equal? rejoin [system/version/1 "." system/version/2] "1.2"][ equal? rejoin [system/version/1 "." system/version/2] "2.5"][ ;do stuff here ] While it seemed to work, I started thinking about /Command and /Express (nee Link), and started thinking that I was in over my head for how tired I was feeling. Hence, leaving the product-version stuff out. Combining the if and either works but suffers from readability (I've never quite figured out how to indent this type of construct for maximum understandability). TM> the only thing i can say is WELL DONE, works great. TM> Just inserted your script into my user.r and off we go, TM> without any problems. Thanks. TM> I kept my self informed that i am using a patched TM> version of REBOL with adding... I am not sure that it is attention-grabbing enough. Just joking! :-) TM> after your script. It is enough for me cause i am TM> mainly working on the console. For apps running TM> in quiet mode this won't be enough. With a slight alteration, it can be made to work with /Core or /View ftp-patch-alert: {++++++++++++++++++++++++++++++++++++++++++++ ATTENTION - ATTENTION - ATTENTION + Your ftp-scheme has been patched to suit international abbreviations. + Please remove this patch from your user.r if you upgrade to a higher + Version in which the problem is fixed by REBOL-Technologies!! + ATTENTION - ATTENTION - ATTENTION + ++++++++++++++++++++++++++++++++++++++++++++} either system/view [ request/ok ftp-patch-alert ][ print ftp-patch-alert ] TM> Disabling the patching by Version verification could be TM> a problem as we don't know the next Version numbers TM> and if the Problem will be fixed in this Release. So, the TM> earliest date we can make the patching related to Versions TM> is when these Versions are out and we could be sure that TM> the problem is fixed. Excellent points! TM> Do you have any other suggestions? No, I really don't. I've truly not had enough experience in this sort of thing. All I would know to do would be to make the patch as specific as possible to products-versions, so that it wouldn't accidentally trash incompatible versions. I would think it would be easier to patch the patch if needed, than have someone spend countless hours tracking down something that was only due to a patch. I will gladly defer to anyone else in this area. Sterling, Volker, Brett? I take on these types of challenges because it helps me to improve my skills and it contributes to the community. Like the ESMTP scheme, I suspect that few will actually need this patch, but I don't know. I do know that for every person who speaks up, there are probably ten others with the same problem who don't speak up. So we never know how many people give up on REBOL just because their first FTP session failed just because the server file dates were localized. This may sound overly dramatic, but when a product line promotes itself as making easy things easy, well, FTP should clearly fall into the easy category. Yes? I am glad that the patch worked. I enjoyed working with you on this mini-task. And thanks to all for the nifty things you taught me! --Scott Jones

> Hi, Thorsten, Sterling, Volker, Brett, > > This volleyball game now spans the globe. Brett, you are really going > to have to hit the ball hard from "Down Under"

> BH> I just want to comment on the patching process. > BH> I recognise that you made the decision to leave > BH> out the check which I respect. ... > > Brett, thank you for being so diplomatic.

> I will gladly defer to anyone > else in this area. Sterling, Volker, Brett?

> I take on these types of challenges because it helps me to improve my > skills and it contributes to the community. Like the ESMTP scheme, I > dramatic, but when a product line promotes itself as making easy things > easy, well, FTP should clearly fall into the easy category. Yes?

[REBOL [] { Hi, Scott, Thorsten, Sterling, Brett, Anton regarding version-security i'm very reluctant to suggest this, after all our clever injection stuff, :) but maybe using the molded source is the safest thing? We can have version-check with 1234 = probe checksum mold ftp we can create patcher with parsing the source, instead of stepping through blocks. (Ok, not really needed.) we can rename the patched protocol, have original ftp:// and patched-ftp:// parallel then. (Hm, a 'make would do this too.) after that we write a %patched-ftp.r to be called by %user.r (more overhead.. but) this should be mostly version-safe? ok, gets pretty long now. maybe simply posting full source ;-) but the [probe checksum] is clever, yes? ;-) (hope it works everywhere..) -Volker } ;------ ;---------------- convert-date-source: { {not handy yet, insert please} } ;---------------- either 5772242 <> probe checksum mold system/schemes/ftp [ request/ok "wrong rebol-version! patched ftp disabled!" ] [ either not parse mold/only system/schemes/ftp [ copy begin thru { add-date: func [] [ month: } copy rest to end ] [request/ok "could not parse right. check script!"] [ body: rejoin [convert-date-source begin " convert-month " rest] save/header save-file: %patched-ftp.r compose/deep [ system/schemes: make system/schemes [ patched-ftp: (load body) ] ] [title: "patched ftp protocol"] ] ;check it do save-file probe first system/schemes ;read patched-ftp://something ] ]

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<

> Hi, Thorsten, Sterling, Volker, Brett, > This volleyball game now spans the globe. Brett, you are really going > to have to hit the ball hard from "Down Under"

Hi Voker,

> but the [probe checksum] is clever, yes? ;-) (hope it works > everywhere..)

Sports Announcer's Voice: ... Volker makes a long lob of the volley ball. It's headed to the back of the court. Scott, who had been guarding the net, suddenly finds he's running to the back of the court. Will he be able to get there in time? ... From: "Volker Nitsch"

> i'm very reluctant to suggest this, after all our > clever injection stuff, :) > but maybe using the molded source is the safest thing?

> We can have version-check with > 1234 = probe checksum mold ftp > > we can create patcher with parsing the source, > instead of stepping through blocks. > (Ok, not really needed.)

> we can rename the patched protocol, have original ftp:// > and patched-ftp:// parallel then. > (Hm, a 'make would do this too.) > > after that we write a %patched-ftp.r to be called by %user.r > (more overhead.. but) > this should be mostly version-safe?

> ok, gets pretty long now. maybe simply posting full source ;-) > but the [probe checksum] is clever, yes? ;-) (hope it works > everywhere..)

> -Volker > }

Sports Announcer's Voice: ...And the volley ball bops Scott right on the nose. Ohhhh. It looks like a nose bleed. Scott goes to the sidelines while Brett takes Scott's place .... OK, I got the errands taken care of (Mother-in-law is coming to visit ... oh, is that the "Ride of the Valkyries" I hear? Just teasing.), and I have now had a chance to look at the code. Let me start by saying that your code is far more clever than I am. After a bit of study, I finally figured out what you were doing. (It reminds of the analogy that I know the notes on a musical scale, but I can't hear the music by just reading a symphonic score like a conductor can. Oh, there's that musical theme, again. Oh, I see, the volley ball game is in a time out and the band is playing! I guess that ball hit harder than I realized.) Once, again, this is amazingly clever stuff that you have written. Bravo. So I inserted the convert-month source into the convert-date-source and braced for the Volker Auto-ftp-scheme-patch-maker. Then, then, then .... my nose started to bleed again. Rats. First, an unexpected blow to the checksum idea. I discovered that my Win98 ftp scheme checksum was 5504709 for /View and 7796860 for /Core. I guess between line terminators and (???) tabs, there seems to be different checksum for different products and platforms! It was really a good idea, too. I changed the checksum to match. Next, I was unable to get the scheme parser to find the beginning of the add-date stuff. So far I have been unable to determine what is causing a mismatch (could it be the brackets?). On a whim, I reduced it to copy through "month:", and it worked correctly. And the script completed without incident. However, placing the "convert-date-source" word in front of the scheme body causes the function definition to preceed the "make object!" Seeing stars .... So I readjust the parse scheme and changed the ordering of the body definition, placing the new function right at the start of the add-date function and success! At least, it appears to be a success, since I cannot check it against a German, etc, localized FTP server. It works on an English localized server. So, there is definite promise in this approach, and of course, I'm speaking beyond this FTP patch issue (I think we all are!?) and to more general distributed patch techniques. This is some nifty, code, Volker. I've learned yet more techniques. Thanks. I'll send the current version back for your information. Note it currently has my checksum value in it. --Scott Jones convert-date-source: { convert-month: func [month [string!] /local conv seek] [ conv: [ Ene "Gen" ["Jan"] Fév "Fev" ["Feb"] Mär ["Mar"] Avr "Abr" ["Apr"] Mag "Mai" ["May"] Giu ["Jun"] Jui "Lug" ["Jul"] Aoû "Ago" ["Aug"] Set ["Sep"] Okt "Ott" "Out" ["Oct"] ; ["Nov"] ; none needed yet Dic "Déc" "Dez" ["Dec"] ] if seek: find conv month [return first first find seek block!] month ] } ;---------------- either 5504709 <> probe checksum mold system/schemes/ftp [ request/ok "wrong rebol-version! patched ftp disabled!" ][ either not parse mold/only system/schemes/ftp [ copy begin to {month:} thru {month:} copy rest to end ][ request/ok "could not parse right. check script!" ][ body: rejoin [begin convert-date-source "month: convert-month " rest] save/header save-file: %patched-ftp.r compose/deep [ system/schemes: make system/schemes [patched-ftp: (load body)] ] [title: "patched ftp protocol"] ] ;check it do save-file probe first system/schemes ;yep, there it is! ;read patched-ftp://something ]