From sschwarzer at sschwarzer.net Fri Jul 7 00:35:42 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 07 Jul 2006 00:35:42 +0200 Subject: [ftputil] Call for votes on new features Message-ID: <44AD903E.8000802@sschwarzer.net> Hello, currently, there are three open tickets on the ftputil website, at http://ftputil.sschwarzer.net/trac/report/1?sort=ticket&asc=1 . In order to know on which of the tickets I should work next, I would like to get your opinions, in form of votes. Here's a short list of the open tickets. You can find a summary and discussion for each on the website under the given links. If something isn't clear there, please ask. *** Ticket #3 - Add caching of stat results http://ftputil.sschwarzer.net/trac/ticket/3 *** Ticket #6 - Add an FTP mirror script http://ftputil.sschwarzer.net/trac/ticket/6 *** Ticket #14 - Support for the REST verb. http://ftputil.sschwarzer.net/trac/ticket/14 *** Ticket #15 - Add support for FXP (FTP to FTP copy) http://ftputil.sschwarzer.net/trac/ticket/15 If you are interested in any or some of the features, please send a mail to this list or to me in private. Under each or under selected tickets above write a number from +3 (highest priority) to +1 (lower priority = would be nice). As a specialty, you can also vote with a -1 (ftputil shouldn't include this). Especially in the latter case, I'd like to know how you come to this opinion. You don't have to vote on all tickets. Here's an example. (Note that this is just an example, not my actual opinion.) === Begin EXAMPLE =============================================== > *** Ticket #3 - Add caching of stat results > http://ftputil.sschwarzer.net/trac/ticket/3 (no opinion) > *** Ticket #6 - Add an FTP mirror script > http://ftputil.sschwarzer.net/trac/ticket/6 -1 (there are enough mirror scripts out there) > *** Ticket #14 - Support for the REST verb. > http://ftputil.sschwarzer.net/trac/ticket/14 +3 > *** Ticket #15 - Add support for FXP (FTP to FTP copy) > http://ftputil.sschwarzer.net/trac/ticket/15 +1 === End EXAMPLE ================================================= Please vote now! :-) Stefan From sschwarzer at sschwarzer.net Fri Jul 7 00:06:52 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 07 Jul 2006 00:06:52 +0200 Subject: [ftputil] Wiki and ticket system restricted to registered users (because of spam) Message-ID: <44AD897C.3000407@sschwarzer.net> Hello, due to much spam in the ftputil ticket system, I have - at least for now - disabled the creation and modification of wiki pages and tickets on the ftputil website at http://ftputil.sschwarzer.net . That means that you must send me an email to get an ftputil account in order to create/change wiki pages and tickets. I'm very sorry for this inconvenience but there were about 20 new spam entries when I returned from EuroPython today. :-/ If you don't want to get an account, you can still mail bug reports or enhancement requests to me or preferably to the mailing list. I try to find out if and how much it's possible to protect trac against spam entries. If feasible, I'll change the trac installation accordingly. I'm also thankful for tips from you. Stefan From martin.wilck at fujitsu-siemens.com Fri Jul 7 16:28:09 2006 From: martin.wilck at fujitsu-siemens.com (Martin Wilck) Date: Fri, 07 Jul 2006 16:28:09 +0200 Subject: [ftputil] Call for votes on new features In-Reply-To: <44AD903E.8000802@sschwarzer.net> References: <44AD903E.8000802@sschwarzer.net> Message-ID: <44AE6F79.4020308@fujitsu-siemens.com> Stefan Schwarzer wrote: > *** Ticket #3 - Add caching of stat results > http://ftputil.sschwarzer.net/trac/ticket/3 > > *** Ticket #6 - Add an FTP mirror script > http://ftputil.sschwarzer.net/trac/ticket/6 You may be interested to know that I have made an extension to ftputil (so far only for my own personal uses) that incorporates these two features. The mirror script uses an rsync-like logic for including and excluding files. I use it regularly as an upload mirror script for a large internal FTP site. Apart from the two features mentioned, it can also (to a certain reasonable extent) deal with FTP servers on broken OSes with case-insensitive file systems. I haven't posted the code here so far because it needs some cleanup and because it was made against ftputil 2.1b. I'll try to get the stuff cleaned up asap, perhaps it can save you some work. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck at Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy From sschwarzer at sschwarzer.net Fri Jul 7 17:55:24 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 07 Jul 2006 17:55:24 +0200 Subject: [ftputil] Call for votes on new features In-Reply-To: <44AE6F79.4020308@fujitsu-siemens.com> References: <44AD903E.8000802@sschwarzer.net> <44AE6F79.4020308@fujitsu-siemens.com> Message-ID: <44AE83EC.5020802@sschwarzer.net> Hi Martin, On 2006-07-07 16:28, Martin Wilck wrote: > Stefan Schwarzer wrote: > >> *** Ticket #3 - Add caching of stat results >> http://ftputil.sschwarzer.net/trac/ticket/3 >> >> *** Ticket #6 - Add an FTP mirror script >> http://ftputil.sschwarzer.net/trac/ticket/6 > > You may be interested to know that I have made an extension to ftputil > (so far only for my own personal uses) that incorporates these two > features. :-) > The mirror script uses an rsync-like logic for including and > excluding files. I use it regularly as an upload mirror script for a > large internal FTP site. Apart from the two features mentioned, it can > also (to a certain reasonable extent) deal with FTP servers on broken > OSes with case-insensitive file systems. > > I haven't posted the code here so far because it needs some cleanup and > because it was made against ftputil 2.1b. From 2.1b to 2.1 only very little has changed, if anything at all. > I'll try to get the stuff cleaned up asap, perhaps it can save you some > work. I suggest that (if you don't mind) you _don't_ clean up the code beforehand, but instead first send it to me as it is. (However, it's important that I get to see only code that I can include under the revised BSD license of ftputil. So if your work is/was related to the work you did for your employer, there may be problems with the usage rights.) So I can think of how it fits into my view of ftputil before you have the clean-up work. And, anyway, I'm curious. :-) Best wishes Stefan From idoa01 at yahoo.com Sat Jul 8 02:51:25 2006 From: idoa01 at yahoo.com (Ido Abramovich) Date: Fri, 7 Jul 2006 17:51:25 -0700 (PDT) Subject: [ftputil] Call for votes on new features In-Reply-To: <44AE83EC.5020802@sschwarzer.net> Message-ID: <20060708005125.50892.qmail@web32902.mail.mud.yahoo.com> Martin - lol :) I also made an rsync compatible script and an extension to ftputil that adds caching (actually, it's a script that adds caching of "dir" calls to ftplib, and I use the factory method to incorporate the extended ftplib into ftputil, I guess that this could be extended to add caching of downloaded files, but I didn't need to at the time) It would be interesting to compare notes. Stefan - could you attach the license and possibly explain the differences between your license and the regular BSD license, or just direct me to an online version of it? I'm not really sure if I can share my code due to my working contract... Oh, and it would be nice to have a "keep alive" method, sometimes my connection dies in the middle due to inactivity... I just found out that it posses a problem to my rsync-like script and I'll have to figure out how to deal with it. a standard caching system gets a +3 from me - even though I'm quite satisfied at the moment with my current solution. Ido. Stefan Schwarzer wrote: Hi Martin, On 2006-07-07 16:28, Martin Wilck wrote: > Stefan Schwarzer wrote: > >> *** Ticket #3 - Add caching of stat results >> http://ftputil.sschwarzer.net/trac/ticket/3 >> >> *** Ticket #6 - Add an FTP mirror script >> http://ftputil.sschwarzer.net/trac/ticket/6 > > You may be interested to know that I have made an extension to ftputil > (so far only for my own personal uses) that incorporates these two > features. :-) > The mirror script uses an rsync-like logic for including and > excluding files. I use it regularly as an upload mirror script for a > large internal FTP site. Apart from the two features mentioned, it can > also (to a certain reasonable extent) deal with FTP servers on broken > OSes with case-insensitive file systems. > > I haven't posted the code here so far because it needs some cleanup and > because it was made against ftputil 2.1b. From 2.1b to 2.1 only very little has changed, if anything at all. > I'll try to get the stuff cleaned up asap, perhaps it can save you some > work. I suggest that (if you don't mind) you _don't_ clean up the code beforehand, but instead first send it to me as it is. (However, it's important that I get to see only code that I can include under the revised BSD license of ftputil. So if your work is/was related to the work you did for your employer, there may be problems with the usage rights.) So I can think of how it fits into my view of ftputil before you have the clean-up work. And, anyway, I'm curious. :-) Best wishes Stefan _______________________________________________ ftputil mailing list ftputil at codespeak.net http://codespeak.net/mailman/listinfo/ftputil --------------------------------- Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060707/4ce505bc/attachment.htm From sschwarzer at sschwarzer.net Sat Jul 8 14:49:24 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Sat, 08 Jul 2006 14:49:24 +0200 Subject: [ftputil] Call for votes on new features In-Reply-To: <20060708005125.50892.qmail@web32902.mail.mud.yahoo.com> References: <20060708005125.50892.qmail@web32902.mail.mud.yahoo.com> Message-ID: <44AFA9D4.7010701@sschwarzer.net> Hi Ido, On 2006-07-08 02:51, Ido Abramovich wrote: > Stefan - could you attach the license and possibly explain the > differences between your license and the regular BSD license, > or just direct me to an online version of it? The license that covers ftputil is at http://www.opensource.org/licenses/bsd-license.php . This is the recommended version. The original BSD license had an additional "advertisement clause" which turned out to be impractical. It's a bit unfortunate that sometimes (often?) the two variants make the BSD license confusing. There's an entry about the BSD licenses in the GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html#OrigBSD . > I'm not really > sure if I can share my code due to my working contract... As far as I know, at least in Germany the case is even problematic if you developed your software in your sparetime but do similar work for your employer. Of course, this isn't the exact appropriate juristic wording. If you've done the work in the work time or with tools provided by the employer, the code probably belongs to him anyway. If you are unsure if you are allowed to donate the code to ftputil, it may be best to _not_ post _any_ of the code. > Oh, and it would be nice to have a "keep alive" method, > sometimes my connection dies in the middle due to inactivity... There was a "keep alive" functionality in ftputil 2.1b but contrary to what I had assumed it didn't work for file-like objects opened for writing. (I had unit tests, but there was a wrong assumption in one of them so it didn't really test all that it should have.) Eventually, I removed it rather than having a "half-working" implementation. BTW, there's also an (unanswered) post by me on the topic on comp.lang.python: http://groups.google.com/group/comp.lang.python/browse_frm/thread/0297d4e4a43c162c/2b8b1b5518e54b49?#2b8b1b5518e54b49 > I just found out that it posses a problem to my rsync-like > script and I'll have to figure out how to deal with it. a > standard caching system gets a +3 from me - even though I'm > quite satisfied at the moment with my current solution. That's something I didn't consider in my post on voting: Some things are easier to implement than others. And unless I've missed something, the caching shouldn't be too difficult (at least easier than adding FXP unless you are very familiar with the file transfer protocol). Stefan From listsin at integrateddevcorp.com Sat Jul 8 22:45:20 2006 From: listsin at integrateddevcorp.com (Lists In@IDC) Date: Sat, 8 Jul 2006 16:45:20 -0400 Subject: [ftputil] Fwd: Call for votes on new features References: <44AE853A.3080704@sschwarzer.net> Message-ID: <1EB4BFCC-D050-4CFF-BB8E-C2667892300A@integrateddevcorp.com> Begin forwarded message: > From: Stefan Schwarzer > Date: July 7, 2006 12:00:58 PM EDT > To: "Lists In at IDC" > Subject: Re: [ftputil] Call for votes on new features > > Hi Steve, > > thanks for your mail. (Was it really indended for my personal mail > or for the list?) If you like, you can send your mail and this > reply to the list. > > On 2006-07-07 17:46, Lists In at IDC wrote: >>> Here's a short list of the open tickets. You can find a summary >>> and discussion for each on the website under the given links. If >>> something isn't clear there, please ask. >>> >>> *** Ticket #3 - Add caching of stat results >>> http://ftputil.sschwarzer.net/trac/ticket/3 >> >> +0 Not necessarily a good idea, in my opinion, and should be >> optional. Would speed up mirroring if you can safely assume nobody's >> going to be doinking anything behind your back while you're doing it, >> would provide a false sense of security if someone was changing >> things behind your back when you thought you were making an up-to- >> date copy. > > 100% agreed. I have thought the same things. So caching would of > course be optional. If it was, how would be your vote? > >>> *** Ticket #6 - Add an FTP mirror script >>> http://ftputil.sschwarzer.net/trac/ticket/6 >> >> +1 I've had pretty good luck with ftpmirror.py but enhancing it with >> ftputil functionality would be pretty cool. >> >>> *** Ticket #14 - Support for the REST verb. >>> http://ftputil.sschwarzer.net/trac/ticket/14 >> >> +2 This would be handy, especially with the mirror option since, as >> we all know, FTP is not perfect. >> >>> *** Ticket #15 - Add support for FXP (FTP to FTP copy) >>> http://ftputil.sschwarzer.net/trac/ticket/15 >> >> +3 I would use this every day. > > Good to know. > > Best wishes > Stefan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060708/79bed759/attachment-0001.htm From vmyrick at zooandaquarium.com Mon Jul 10 15:42:14 2006 From: vmyrick at zooandaquarium.com (Verona Myrick) Date: Mon, 10 Jul 2006 14:42:14 +0100 Subject: [ftputil] Eunice Lyons Message-ID: <1152538934.9223@zooandaquarium.com> An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060710/e9a97005/attachment.htm From martin.wilck at fujitsu-siemens.com Wed Jul 19 12:08:16 2006 From: martin.wilck at fujitsu-siemens.com (Martin Wilck) Date: Wed, 19 Jul 2006 12:08:16 +0200 Subject: [ftputil] My ftputil extensions (caching/mirror script) In-Reply-To: <44BAD40B.100@sschwarzer.net> References: <44AD903E.8000802@sschwarzer.net> <44AE6F79.4020308@fujitsu-siemens.com> <44AE83EC.5020802@sschwarzer.net> <44B5611E.4030205@fujitsu-siemens.com> <44BAD40B.100@sschwarzer.net> Message-ID: <44BE0490.4010902@fujitsu-siemens.com> Hi Stefan, > you sent your mail in private. I don't know for sure if the > mailing list strips attachments, so the private mail might > actually have been sensible. ;-) What do you think about > continuing the discussion on the mailing list? Fine with me. I thought it'd be good to let you see the code first, and that not all of it would be of interest to the list members. CC'ing the list now. (List members: I had sent my code based on ftputil mentioned in the "Call for votes on new features" thread to Stefan. If anyone else wants to see it, drop me an email, or tell me to post it to the list). >>The caching is implemented in a very simplistic manner (just store the >>_dir() results), but that saves a lot of execution time for me. I wanted >>to re-implement as little as possible ftputil code. > > > Understandable. I'm not yet sure if I'll add caching of _dir() > results or of individual stat results. Caching stat results will be more efficient because, in my current implemtation, if one entry changes, the stat info of all other files in the same directory will have to be invalidated. >>The handling of case-insensitive FTP servers took me much more work, a >>lot of the code is actually devoted to that (you might figure that I >>came up with that because I had a lot of trouble with such a server). > > > I won't approach case-insensitive servers for now; I'll tackle > the caching first. In fact, I try to solve this rather > minimalistic, without adding code unnecessary for the caching > task. Agreed. I suspect that the case-insensitive-server thing is a very specific problem of mine. And it is pretty hard to say what is The Right Thing(TM) when uploading from a case sensitve system to a case insensitive system. >>I haven't figured out yet which parts of this code could be integrated >>into ftputil, and how. If you are interested, I expect that we'll >>consider that together. > > > I've not (yet) a firm idea at this point, too. I think there will > be a module stat_cache.py and an interface to set cache > parameters in the FTPHost class. This interface should be careful > to not expose implementation details of the caching, because > > - the interface should provide a high-level view of the caching > (being high-level is IMHO the main strength of ftputil w.r.t. > ftplib, after all); > > - exposing implementation details would make it more difficult to > change the caching implementation or details of it later > > An interface might be > > host = ftputil.FTPHost(...) > # set number of cached entries and their maximum age > host.cache_control(max_entries=1000, max_age=10*60) > > and perhaps an interface for invalidating the cache > > host.empty_cache() > > with > > def cache_control(self, max_entries=0, max_age=0): > """ > Set parameters to control the cache for dir/file stat > results. There's one cache per `FTPHost` instance. > > `max_entries` is the maximum number of entries to store in > the cache; i. e. there will never be more than `max_entries` > stat result items in the cache. > > `max_age` is the maximum age of the cache entries; if an > entry is older it will _not_ be reused from the cache but the > information will be fetched from the FTP host. > > The defaults for both `max_entries` and `max_age` is 0 which > implicitly disables the cache. This is for backwards > compatibilty with old versions of ftputil. These settings > also avoid possibly unwanted side effects on items changing > on the server by other ways than this `FTPHost` instance. > """ > > def empty_cache(self): > """ > Empty the cache for stat results. After that call, caching > will restart for new stat queries. > > To switch off caching for the `FTPHost` instance completely, > use > > host.cache_control(max_age=0) > """ > > The names of the methods and their parameters aren't carved in > stone. Sounds very reasonable to me. I am just wondering whether or not you should put this functionality into a derived class 'CachingFTPHost', as I needed to, or just extend 'FTPHost' itself. >>I hope you like the stuff, looking forward to your feedback, > > > I read your code without trying to understand every detail. So > far, it seems very understandable for what it's trying to solve. > _For ftputil_, though, I'll try _not_ to write general-purpose > code, but just enough to implement the caching to avoid fetching > directory lists for each single file/directory entry. I like the > YAGNI and DTSTTCPW principles > ( http://c2.com/xp/YouArentGonnaNeedIt.html and > http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork ). I am not sure I fully understand what you mean, but with these principles in mind and with the goal you're stating, simp,y caching _dir() results might be the best thing you can do. Regards Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck at Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy From danmil at comcast.net Wed Jul 19 21:57:08 2006 From: danmil at comcast.net (Dan Milstein) Date: Wed, 19 Jul 2006 15:57:08 -0400 Subject: [ftputil] Stat'ing a Whole Directory Message-ID: <71478D44-887F-421A-BF84-B7E82B3D8D82@comcast.net> FTPUtil Folk, I've been using the lovely ftputil lib, and, basically, it's fab. However, for my app, I need to produce detailed directory listings for the files on the remote server. With the current interface, that means getting the list of all files (one remote call), and then fetching that entire list over and over in order to stat each individual file (a remote call for every file). There's already a ticket for caching stat results, but what works better for me is to add a new call: host.statdir(path) (or host.lstatdir(path), if that makes more sense -- I'm not the most perfectly clear on how symbolic links interact with ftp). The call returns a list of stat results, making a single remote call and then parsing the entire list. This gets around the need for caching (which I'd prefer to avoid, because of synchronization issues), and has very nice performance. I've actually patched ftputil and ftp_stat with the necessary code to do this. I'd be happy to send along patches for those files, or just include the code in an email. -Dan Milstein From sschwarzer at sschwarzer.net Thu Jul 20 00:19:18 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Thu, 20 Jul 2006 00:19:18 +0200 Subject: [ftputil] My ftputil extensions (caching/mirror script) In-Reply-To: <44BE0490.4010902@fujitsu-siemens.com> References: <44AD903E.8000802@sschwarzer.net> <44AE6F79.4020308@fujitsu-siemens.com> <44AE83EC.5020802@sschwarzer.net> <44B5611E.4030205@fujitsu-siemens.com> <44BAD40B.100@sschwarzer.net> <44BE0490.4010902@fujitsu-siemens.com> Message-ID: <44BEAFE6.5060408@sschwarzer.net> Hello Martin, On 2006-07-19 12:08, Martin Wilck wrote: > (List members: I had sent my code based on ftputil mentioned in the > "Call for votes on new features" thread to Stefan. If anyone else wants > to see it, drop me an email, or tell me to post it to the list). The code is already in a branch on ftputil.sschwarzer.net :-) http://ftputil.sschwarzer.net/trac/browser/branches/add_stat_caching/ftpsync-0.1 >>> The caching is implemented in a very simplistic manner (just store the >>> _dir() results), but that saves a lot of execution time for me. I wanted >>> to re-implement as little as possible ftputil code. >> >> Understandable. I'm not yet sure if I'll add caching of _dir() >> results or of individual stat results. > > Caching stat results will be more efficient because, in my current > implemtation, if one entry changes, the stat info of all other files in > the same directory will have to be invalidated. The approach and the implementation have to work together. We can use a present implementation but we don't _have to_, so we are free in which approach we use. :-) >>> I haven't figured out yet which parts of this code could be integrated >>> into ftputil, and how. If you are interested, I expect that we'll >>> consider that together. >> >> I've not (yet) a firm idea at this point, too. I think there will >> be a module stat_cache.py and an interface to set cache >> parameters in the FTPHost class. This interface should be careful >> to not expose implementation details of the caching, because >> >> - the interface should provide a high-level view of the caching >> (being high-level is IMHO the main strength of ftputil w.r.t. >> ftplib, after all); >> >> - exposing implementation details would make it more difficult to >> change the caching implementation or details of it later >> >> An interface might be >> >> host = ftputil.FTPHost(...) >> # set number of cached entries and their maximum age >> host.cache_control(max_entries=1000, max_age=10*60) >> >> and perhaps an interface for invalidating the cache >> >> host.empty_cache() >> >> with >> >> def cache_control(self, max_entries=0, max_age=0): >> """ >> Set parameters to control the cache for dir/file stat >> results. There's one cache per `FTPHost` instance. >> >> `max_entries` is the maximum number of entries to store in >> the cache; i. e. there will never be more than `max_entries` >> stat result items in the cache. >> >> `max_age` is the maximum age of the cache entries; if an >> entry is older it will _not_ be reused from the cache but the >> information will be fetched from the FTP host. >> >> The defaults for both `max_entries` and `max_age` is 0 which >> implicitly disables the cache. This is for backwards >> compatibilty with old versions of ftputil. These settings >> also avoid possibly unwanted side effects on items changing >> on the server by other ways than this `FTPHost` instance. >> """ >> >> def empty_cache(self): >> """ >> Empty the cache for stat results. After that call, caching >> will restart for new stat queries. >> >> To switch off caching for the `FTPHost` instance completely, >> use >> >> host.cache_control(max_age=0) >> """ >> >> The names of the methods and their parameters aren't carved in >> stone. > > Sounds very reasonable to me. I am just wondering whether or not you > should put this functionality into a derived class 'CachingFTPHost', as > I needed to, or just extend 'FTPHost' itself. Interface-wise, I would prefer to have the caching in `FTPHost`. As I wrote, by default the caching will (effectively) be switched off (to prevent unexpected side effects) so a user of `FTPHost` can start using the caching feature at any time without having to change the class. Best wishes Stefan From calvarez at zooandaquarium.com Thu Jul 20 04:42:13 2006 From: calvarez at zooandaquarium.com (Charlene Alvarez) Date: Wed, 19 Jul 2006 21:42:13 -0500 Subject: [ftputil] Melida Stpierre Message-ID: <1153363333.145646@zooandaquarium.com> An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060719/142cd59d/attachment-0001.htm From danmil at comcast.net Thu Jul 20 20:39:05 2006 From: danmil at comcast.net (Dan Milstein) Date: Thu, 20 Jul 2006 14:39:05 -0400 Subject: [ftputil] Stat'ing a Whole Directory Message-ID: a) BSD license -- would be delighted. Very happy to contribute. b) My code -- I'll clean up what I've got and post it today or tomorrow. c) Low-level/high-lvel A thought: yes, returning a list of stat results feels a bit low- level. Esp since the reason I need the stat results and not just the names is to do things like isfile() and isdir(), which I can then only do by explicitly calling stat.S_ISDIR(stat_result.st_mode). Blech. What might be nice, but would move just a bit away from the os.path analogy, would be to make ftphost.path be able to run isfile()/isdir ()/etc on both path names and also FTPFile objects (or something like FTPFile objects -- see below). Would that be something you might be interested in seeing? I'd be happy to write it. Before I dive in, I wanted to see if you (or anyone else on the list) thinks that might belong in the distribution. If you are interested, what I'd like to do is add a method to ftphost: getfiles(path) Which returns a list of FTPFile-like objects (with stat and path information hidden in them). They would lazily support the file interface, but would only connect to the remote server if someone actually reads or writes their contents. And then I would extend ftp_path.isdir()/isfile()/etc to handle those objects as well as path names. So that, if you need to operate on a directory, to say, copy all files, and recurse over all subdirectories, you could do something like: def copy_all_files(path): for f in ftphost.getfiles(path): if ftphost.path.isdir(f): copy_all_files(f.path) else: ftphost.copyfileobj(f, file(f.name)) Which feels fairly clean and intuitive, and would behave pretty nicely in terms of how it hits the remote server (whereas, with the current implementation, the lib is fetching the entire directory listing over and over again for every call to isdir()). Does that make sense? If not, should I just code it up so you can play with it? ;-) -Dan On Jul 19, 2006, at 6:42 PM, Stefan Schwarzer wrote: > Hi Dan, > > On 2006-07-19 21:57, Dan Milstein wrote: >> I've been using the lovely ftputil lib, and, basically, it's fab. > > thanks :-) > >> However, > > aah, now ... ;-) > >> for my app, I need to produce detailed directory listings >> for the files on the remote server. With the current interface, that >> means getting the list of all files (one remote call), and then >> fetching that entire list over and over in order to stat each >> individual file (a remote call for every file). >> >> There's already a ticket for caching stat results, but what works >> better for me is to add a new call: >> >> host.statdir(path) >> >> (or host.lstatdir(path), if that makes more sense -- I'm not the most >> perfectly clear on how symbolic links interact with ftp). >> >> The call returns a list of stat results, making a single remote call >> and then parsing the entire list. This gets around the need for >> caching (which I'd prefer to avoid, because of synchronization >> issues), and has very nice performance. > > This is a good idea! Nonetheless I'm a bit hesitant to use it in > ftputil, because this is somewhat "low-level", compared with the > usual ftputil mindset. > > I'm _very_ interested what the others on the list think! > >> I've actually patched ftputil and ftp_stat with the necessary code to >> do this. I'd be happy to send along patches for those files, or just >> include the code in an email. > > _Please_ send the patch(es) to the mailing list(*), so anyone who > wants to try the code (and how its usage "feels") can do it. If > you can, make a single patch for all affected files. I'm not 100% > sure if the list accepts attachments. If your mail bounces, > please include the patch into the normal text and resend it. > > (*) Before you post, think about whether you can and want to put > the code under the BSD license that ftputil uses. Strictly > speaking, this is only relevant for inclusion of the code into > ftputil but I also read the list, of course, and I wouldn't want > to accidently put code from my memory into ftputil which doesn't > belong there. > > Best wishes > Stefan From danmil at comcast.net Thu Jul 20 23:33:18 2006 From: danmil at comcast.net (Dan Milstein) Date: Thu, 20 Jul 2006 17:33:18 -0400 Subject: [ftputil] statdir patches Message-ID: <97E8A77B-ADAE-4CD9-BD7A-0ADEC5243934@comcast.net> All, Here, as both a single attachment and also inline in the email, are a pair of patches for ftputil.py and ftp_stat.py. They implement a new method for ftphost: > ftphost.statdir(path) statdir returns a list of stat_result objects for the files on the remote server in the directory 'path'. This allows for an efficient, if slightly low-level, means of examining a potentially long list of files on a remote server, and taking action based on modification dates, directory/file nature, etc. Stefan: let me know if you need any official thing to say "Yes, I submit this code to the project and release it under a BSD license". -Dan --- ../ftputil-2.1/ftputil.py 2006-03-01 19:55:46.000000000 -0500 +++ ftputil.py 2006-07-20 17:25:48.000000000 -0400 @@ -697,6 +697,20 @@ """ return self._stat.stat(path, _exception_for_missing_path) + def statdir(self, path, _exception_for_missing_path=True): + """ + Return a list of "stat" info for each file in the directory `path`. + + If the directory `path` can't be parsed, raise a `ParserError`. If + the directory containing `path` can be parsed but the `path` can't + be found, raise a `PermanentError`. + + (`_exception_for_missing_path` is an implementation aid and + _not_ intended for use by ftputil clients.) + + """ + return self._stat.statdir(path, _exception_for_missing_path=True) + def walk(self, top, topdown=True, onerror=None): """ Iterate over directory tree and return a tuple (dirpath, --- ../ftputil-2.1/ftp_stat.py 2006-02-19 12:01:38.000000000 -0500 +++ ftp_stat.py 2006-07-20 17:26:07.000000000 -0400 @@ -449,6 +449,36 @@ # remember the path we have encountered visited_paths[path] = True + def _real_statdir(self, path, _exception_for_missing_path=True): + """ + Return a list of "stat" info for each file in the directory `path`. + Do not follow symbolic links (i.e. like "lstat") + + If the directory `path` can't be parsed, raise a `ParserError`. If + the directory containing `path` can be parsed but the `path` can't + be found, raise a `PermanentError`. + + (`_exception_for_missing_path` is an implementation aid and + _not_ intended for use by ftputil clients.) + + """ + # get output from FTP's `DIR` command + lines = [] + path = self._path.abspath(path) + lines = self._host_dir(path) + result = [] + for line in lines: + try: + stat_result = self._parser.parse_line(line, + self._host.time_shift()) + result.append(stat_result) + except ftp_error.ParserError: + # ignore things like "total 17", as found in some + # server listings + if not line.lower().startswith("total"): + raise + return result + def __call_with_parser_retry(self, method, *args, **kwargs): """ Call `method` with the `args` and `kwargs` once. If that @@ -483,3 +513,6 @@ return self.__call_with_parser_retry(self._real_stat, path, _exception_for_missing_path) + def statdir(self, path, _exception_for_missing_path=True): + return self.__call_with_parser_retry(self._real_statdir, path, + _exception_for_missing_path) -------------- next part -------------- A non-text attachment was scrubbed... Name: ftputil.patch Type: application/octet-stream Size: 2906 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060720/a2cefabe/attachment.obj From sschwarzer at sschwarzer.net Fri Jul 21 01:17:14 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 21 Jul 2006 01:17:14 +0200 Subject: [ftputil] Stat'ing a Whole Directory In-Reply-To: References: Message-ID: <44C00EFA.2060505@sschwarzer.net> Hi Dan, On 2006-07-20 20:39, Dan Milstein wrote: > c) Low-level/high-lvel > > A thought: yes, returning a list of stat results feels a bit low- > level. Esp since the reason I need the stat results and not just the > names is to do things like isfile() and isdir(), which I can then > only do by explicitly calling stat.S_ISDIR(stat_result.st_mode). Blech. hm, so I currently don't think that this is the way to go. > What might be nice, but would move just a bit away from the os.path > analogy, would be to make ftphost.path be able to run isfile()/isdir > ()/etc on both path names and also FTPFile objects (or something like > FTPFile objects -- see below). What I would like to avoid is to add an interface that basically does the same as an already present interface. Look at the current Python way to get the length of a string: len(s) . A similar interface, regarding the purpose, might be s.len() . Note that I don't say that the former way is better, just that there shouldn't be an _additional_ way if there is already one. > If you are interested, what I'd like to do is add a method to ftphost: > > getfiles(path) Should the files be opened in text or binary mode? Should they be opened for reading or writing? At the moment, this could be implemented like this (below), assuming you want files to be read in binary mode (untested code, beware): def getfiles(path): files = [] cwd = host.getcwd() for name in host.listdir(path): complete_path = host.path.join(cwd, name) if host.path.isfile(complete_path): files.append(host.file(complete_path, 'rb')) return files or, assuming this is a method of `FTPHost`, def getfiles(self, path): files = [] cwd = self.getcwd() for name in self.listdir(path): absolute_path = self.path.join(cwd, name) if self.path.isfile(absolute_path): files.append(self.file(absolute_path, 'rb')) return files (I only wrote this code down to see how much effort could be saved by having the new method. Another criterion is the actual usefulness.) > Which returns a list of FTPFile-like objects (with stat and path > information hidden in them). They would lazily support the file > interface, but would only connect to the remote server if someone > actually reads or writes their contents. And then I would extend > ftp_path.isdir()/isfile()/etc to handle those objects as well as path > names. > > So that, if you need to operate on a directory, to say, copy all > files, and recurse over all subdirectories, you could do something like: > > def copy_all_files(path): > for f in ftphost.getfiles(path): > if ftphost.path.isdir(f): > copy_all_files(f.path) > else: > ftphost.copyfileobj(f, file(f.name)) The `path` and `name` attributes are a bit tricky. Should `path` be the absolute path of the file/directory of the server, and `name` just the tail of the path, similar to what `os.path.basename(path)` returns? If yes, your code iterates recursively through a directory on the server and copies all the files into a single directory on the client's local host (actually without closing the files). Let me try an alternative implementation which uses the current `FTPHost` class (again, untested). def copy_all_files(host, path): for dir_path, dir_names, file_names in host.walk(path): for file_name in file_names: absolute_path = host.path.join(dir_path, file_name) host.download(absolute_path, file_name) > Which feels fairly clean and intuitive, My code feels about as clean and intuitive, I hope. :-) > and would behave pretty > nicely in terms of how it hits the remote server (whereas, with the > current implementation, the lib is fetching the entire directory > listing over and over again for every call to isdir()). Of course, the _current_ performance isn't good, that's why we started to discuss caching, after all. However, I would like to improve the performance _for the current interface_, don't add an additional interface and let the client deal with the right interface to improve performance. In that case, the "server" (ftputil) code is lazy, shifting the responsibility of optimization to every client (user of ftputil). IMHO, it should be the other way around: ftputil should improve it's performance while keeping its interface, thus making it easy for users of the module. Of course, there's a tradeoff: If ftputil doesn't expose the means for its optimizations, clients have to cope with it; they won't be able (or not as easily) to fiddle with ftputil to gain better performance. On the other hand, that's the same kind of tradeoff when we choose Python (less control, easier to use) over C (potentially more control, more difficult to use). Best wishes Stefan From sschwarzer at sschwarzer.net Fri Jul 21 01:38:59 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 21 Jul 2006 01:38:59 +0200 Subject: [ftputil] Stat'ing a Whole Directory Message-ID: <44C01413.8080401@sschwarzer.net> I just noticed that I had sent this mail to Dan in private though it was intended for the list. -------- Original Message -------- Subject: Re: [ftputil] Stat'ing a Whole Directory Date: Thu, 20 Jul 2006 00:42:42 +0200 From: Stefan Schwarzer To: Dan Milstein References: <71478D44-887F-421A-BF84-B7E82B3D8D82 at comcast.net> Hi Dan, On 2006-07-19 21:57, Dan Milstein wrote: > I've been using the lovely ftputil lib, and, basically, it's fab. thanks :-) > However, aah, now ... ;-) > for my app, I need to produce detailed directory listings > for the files on the remote server. With the current interface, that > means getting the list of all files (one remote call), and then > fetching that entire list over and over in order to stat each > individual file (a remote call for every file). > > There's already a ticket for caching stat results, but what works > better for me is to add a new call: > > host.statdir(path) > > (or host.lstatdir(path), if that makes more sense -- I'm not the most > perfectly clear on how symbolic links interact with ftp). > > The call returns a list of stat results, making a single remote call > and then parsing the entire list. This gets around the need for > caching (which I'd prefer to avoid, because of synchronization > issues), and has very nice performance. This is a good idea! Nonetheless I'm a bit hesitant to use it in ftputil, because this is somewhat "low-level", compared with the usual ftputil mindset. I'm _very_ interested what the others on the list think! > I've actually patched ftputil and ftp_stat with the necessary code to > do this. I'd be happy to send along patches for those files, or just > include the code in an email. _Please_ send the patch(es) to the mailing list(*), so anyone who wants to try the code (and how its usage "feels") can do it. If you can, make a single patch for all affected files. I'm not 100% sure if the list accepts attachments. If your mail bounces, please include the patch into the normal text and resend it. (*) Before you post, think about whether you can and want to put the code under the BSD license that ftputil uses. Strictly speaking, this is only relevant for inclusion of the code into ftputil but I also read the list, of course, and I wouldn't want to accidently put code from my memory into ftputil which doesn't belong there. Best wishes Stefan From sschwarzer at sschwarzer.net Fri Jul 21 01:48:55 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 21 Jul 2006 01:48:55 +0200 Subject: [ftputil] Which Python version(s) do you use? Message-ID: <44C01667.3000903@sschwarzer.net> Hello, when I released ftputil for the first time, Python 2.2 had just been released (or was about to be released). So I tried to make ftputil compatible with Python versions starting at 2.1, which required some compromises. I would like to make use of the features added in 2.2. This would allow to remove e. g. the UserTuple class and the extra handling of the True/False values (though they were introduced in Python 2.2.1, not 2.2, if I remember correctly). Thus my question: Which is the lowest Python version you use with ftputil? Would it be ok to drop compatibility with Python versions < 2.2.1 with the release of ftputil 2.2? Or do you really depend on earlier Python versions, i. e. can only switch to a newer version with much effort? Stefan From listsin at integrateddevcorp.com Fri Jul 21 05:00:48 2006 From: listsin at integrateddevcorp.com (Lists In@IDC) Date: Thu, 20 Jul 2006 23:00:48 -0400 Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <44C01667.3000903@sschwarzer.net> References: <44C01667.3000903@sschwarzer.net> Message-ID: <5DD57B30-9CDD-4C63-B645-93BCF19B5E26@integrateddevcorp.com> I'm using 2.4.3 everywhere and will move to 2.5 as soon as it's released. I'm not a big fan, personally, of crippling utility software like ftputil to remain compatible with older versions of tools since the people who are likely to be using it are also likely to be able to keep themselves in an up to date environment. S On Jul 20, 2006, at 7:48 PM, Stefan Schwarzer wrote: > Hello, > > when I released ftputil for the first time, Python 2.2 had just > been released (or was about to be released). So I tried to make > ftputil compatible with Python versions starting at 2.1, which > required some compromises. I would like to make use of the > features added in 2.2. This would allow to remove e. g. the > UserTuple class and the extra handling of the True/False values > (though they were introduced in Python 2.2.1, not 2.2, if I > remember correctly). > > Thus my question: Which is the lowest Python version you use with > ftputil? Would it be ok to drop compatibility with Python > versions < 2.2.1 with the release of ftputil 2.2? Or do you > really depend on earlier Python versions, i. e. can only switch > to a newer version with much effort? > > Stefan > > _______________________________________________ > ftputil mailing list > ftputil at codespeak.net > http://codespeak.net/mailman/listinfo/ftputil > > From andrew.ittner at usa.net Fri Jul 21 05:39:47 2006 From: andrew.ittner at usa.net (Andrew Ittner) Date: Thu, 20 Jul 2006 20:39:47 -0700 Subject: [ftputil] Which Python version(s) do you use? Message-ID: <000901c6ac77$50149650$0401a8c0@xurvm> I second this comment - I use 2.4.2 currently, always try to remain within 6 months of the latest stable version, and never worry about going backwards. Yes, please drop support of anything earlier than 2.3. Frankly, even going with a minimum of 2.4 would be just as good - assuming that makes your life easier. Andrew Ittner >I'm using 2.4.3 everywhere and will move to 2.5 as soon as it's >released. > >I'm not a big fan, personally, of crippling utility software like >ftputil to remain compatible with older versions of tools since the >people who are likely to be using it are also likely to be able to >keep themselves in an up to date environment. > >S > >On Jul 20, 2006, at 7:48 PM, Stefan Schwarzer wrote: > >> Hello, >> >> when I released ftputil for the first time, Python 2.2 had just >> been released (or was about to be released). So I tried to make >> ftputil compatible with Python versions starting at 2.1, which >> required some compromises. I would like to make use of the >> features added in 2.2. This would allow to remove e. g. the >> UserTuple class and the extra handling of the True/False values >> (though they were introduced in Python 2.2.1, not 2.2, if I >> remember correctly). >> >> Thus my question: Which is the lowest Python version you use with >> ftputil? Would it be ok to drop compatibility with Python >> versions < 2.2.1 with the release of ftputil 2.2? Or do you >> really depend on earlier Python versions, i. e. can only switch >> to a newer version with much effort? >> >> Stefan From sschwarzer at sschwarzer.net Fri Jul 21 12:54:36 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 21 Jul 2006 12:54:36 +0200 Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <000901c6ac77$50149650$0401a8c0@xurvm> References: <000901c6ac77$50149650$0401a8c0@xurvm> Message-ID: <44C0B26C.9070301@sschwarzer.net> Hi Andrew, nice to read you again :) On 2006-07-21 05:39, Andrew Ittner wrote: > I second this comment - I use 2.4.2 currently, always try to remain within 6 > months of the latest stable version, and never worry about going backwards. > Yes, please drop support of anything earlier than 2.3. Frankly, even going > with a minimum of 2.4 would be just as good - assuming that makes your life > easier. Personally, I would like to go with Python 2.4. I'm inclined to always use the newest version my Gentoo Linux has as "stable". When asking my question I had rather those people in mind which work for an employer where the IT infrastructure is difficult for them to influence. For example, such an ftputil user might not be able to update to a recent Python version without discussing it with the whole IT department or management. Ok, perhaps such scenarios are not as frequent as Dilbert cartoons suggest. ;-) So now the question doesn't no longer seem to be if ftputil should require Python 2.2.1, but rather if ftputil should/could require an even higher version! Python 2.3 or 2.4? ftputil users, speak up! :-) Stefan From listsin at integrateddevcorp.com Fri Jul 21 14:09:10 2006 From: listsin at integrateddevcorp.com (Lists In@IDC) Date: Fri, 21 Jul 2006 08:09:10 -0400 Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <44C0B26C.9070301@sschwarzer.net> References: <000901c6ac77$50149650$0401a8c0@xurvm> <44C0B26C.9070301@sschwarzer.net> Message-ID: <916BBBC6-63FE-4E06-82E1-269D3332869A@integrateddevcorp.com> On Jul 21, 2006, at 6:54 AM, Stefan Schwarzer wrote: > Hi Andrew, > > nice to read you again :) > > On 2006-07-21 05:39, Andrew Ittner wrote: >> I second this comment - I use 2.4.2 currently, always try to >> remain within 6 >> months of the latest stable version, and never worry about going >> backwards. >> Yes, please drop support of anything earlier than 2.3. Frankly, >> even going >> with a minimum of 2.4 would be just as good - assuming that makes >> your life >> easier. > > Personally, I would like to go with Python 2.4. I'm inclined to > always use the newest version my Gentoo Linux has as "stable". I think the 6 months as 'stable' test is probably a pretty good one. > When asking my question I had rather those people in mind which work > for an employer where the IT infrastructure is difficult for them > to influence. For example, such an ftputil user might not be able to > update to a recent Python version without discussing it with the > whole IT department or management. Ok, perhaps such scenarios are > not as frequent as Dilbert cartoons suggest. ;-) And, since this is a set of utility functions, they're probably running it on their own local machine over which they probably have complete control. Not only that, but there's always /usr/local for non-offical versions. > So now the question doesn't no longer seem to be if ftputil should > require Python 2.2.1, but rather if ftputil should/could require an > even higher version! Python 2.3 or 2.4? ftputil users, speak up! :-) 2.4, and I'd suggest NOT programming around any deficiencies in early 2.4.x versions -- anyone using any major (2.4.xx) branch of a language would be well advised to keep up with the minor security/bug fix versions and wasting programming effort on workarounds is never productive. S From idoa01 at yahoo.com Fri Jul 21 15:57:42 2006 From: idoa01 at yahoo.com (Ido Abramovich) Date: Fri, 21 Jul 2006 06:57:42 -0700 (PDT) Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <44C01667.3000903@sschwarzer.net> Message-ID: <20060721135742.86195.qmail@web32903.mail.mud.yahoo.com> I'm currently using python 2.3.5 at home and office. I'll probably move to python 2.4.x at home when python 2.5 will be available. at work I'll probably still use 2.3.5 (debian stable version. although, there is also ver. 2.4.1 in debian stable, so technically, I can move to that version) there should be no need to support versions <2.3. what features do you want to use that aren't supported with 2.3.x with __future__? Ido. Stefan Schwarzer wrote: Hello, when I released ftputil for the first time, Python 2.2 had just been released (or was about to be released). So I tried to make ftputil compatible with Python versions starting at 2.1, which required some compromises. I would like to make use of the features added in 2.2. This would allow to remove e. g. the UserTuple class and the extra handling of the True/False values (though they were introduced in Python 2.2.1, not 2.2, if I remember correctly). Thus my question: Which is the lowest Python version you use with ftputil? Would it be ok to drop compatibility with Python versions < 2.2.1 with the release of ftputil 2.2? Or do you really depend on earlier Python versions, i. e. can only switch to a newer version with much effort? Stefan _______________________________________________ ftputil mailing list ftputil at codespeak.net http://codespeak.net/mailman/listinfo/ftputil --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060721/72401842/attachment.htm From sschwarzer at sschwarzer.net Fri Jul 21 16:14:55 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 21 Jul 2006 16:14:55 +0200 Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <20060721135742.86195.qmail@web32903.mail.mud.yahoo.com> References: <20060721135742.86195.qmail@web32903.mail.mud.yahoo.com> Message-ID: <44C0E15F.1080806@sschwarzer.net> Hi Ido, On 2006-07-21 15:57, Ido Abramovich wrote: > > I'm currently using python 2.3.5 at home and office. I'll > > probably move to python 2.4.x at home when python 2.5 will be > > available. at work I'll probably still use 2.3.5 (debian stable > > version. although, there is also ver. 2.4.1 in debian stable, > > so technically, I can move to that version) the point that there are still operating systems out there which ship with Python 2.3.x is a good one. :-) In fact, I have a server with Debian Sarge and a notebook with Mac OS X 10.3, which also ships with Python 2.3.x (but I don't use ftputil on these systems). From my experience, while it's technically possible to install Python 2.4 on a Debian system it may quickly become a hassle to find appropriate versions of extensions which use Python 2.4 instead of 2.3 as dependency. Of course, you could install Python 2.4 in your home directory and install all extensions you want there as well, but ... ;-) > > there should be no need to support versions <2.3. what features > > do you want to use that aren't supported with 2.3.x with > > __future__? If I understand your question correctly, you are asking what features in Python 2.4 I would want to use that are not also possible in Python 2.3 with `__future__` imports? Answer: At some point, decorators might be interesting, though I don't have a particular feature in mind that would require or make heavy use of them. I like decorators, but I wouldn't use them for just this reason. ;-) Stefan From sschwarzer at sschwarzer.net Fri Jul 21 16:40:23 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 21 Jul 2006 16:40:23 +0200 Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <916BBBC6-63FE-4E06-82E1-269D3332869A@integrateddevcorp.com> References: <000901c6ac77$50149650$0401a8c0@xurvm> <44C0B26C.9070301@sschwarzer.net> <916BBBC6-63FE-4E06-82E1-269D3332869A@integrateddevcorp.com> Message-ID: <44C0E757.6070402@sschwarzer.net> Hi S (real name not disclosed ;-) ), On 2006-07-21 14:09, Lists In at IDC wrote: >> When asking my question I had rather those people in mind which work >> for an employer where the IT infrastructure is difficult for them >> to influence. For example, such an ftputil user might not be able to >> update to a recent Python version without discussing it with the >> whole IT department or management. Ok, perhaps such scenarios are >> not as frequent as Dilbert cartoons suggest. ;-) > > And, since this is a set of utility functions, they're probably > running it on their own local machine over which they probably have > complete control. Not only that, but there's always /usr/local for > non-offical versions. In a Python project, we had quite some infrastructure (webserver, database, application server, ...). We didn't make the effort to install all this software and the test data on every developer's machine. Instead, we installed most of the infrastructure only once on a shared development server. If a developer doesn't have admin rights on such a server, he can't install ftputil in /usr/local (however, in his/her home directory, but that doesn't make sense, if code using ftputil should be used in production). So my current point of view is: The step from Python 2.1 to Python 2.2 is the most significant up all updates so far. Python 2.3 gives a bit more. Python 2.4 doesn't provide much more than Python 2.3 (compared with the steps from 2.1 to 2.2, or 2.2 to 2.3). Ok, there are very useful additions, e. g. decorators or the subprocess module, but those aren't particularly needed by ftputil (at least not yet). >> So now the question doesn't no longer seem to be if ftputil should >> require Python 2.2.1, but rather if ftputil should/could require an >> even higher version! Python 2.3 or 2.4? ftputil users, speak up! :-) > > 2.4, and I'd suggest NOT programming around any deficiencies in early > 2.4.x versions -- anyone using any major (2.4.xx) branch of a > language would be well advised to keep up with the minor security/bug > fix versions and wasting programming effort on workarounds is never > productive. I'm not sure of this. You should install security updates, true. On the other hand, some minor Python versions don't include security fixes but add new features. To avoid confusion among developers using Python 2.x.y (0 <= y <= ymax), I would only require 2.x(.0) instead of 2.x.ymax. Stefan From vpogrebi at comcast.net Fri Jul 21 16:44:53 2006 From: vpogrebi at comcast.net (Valeriy Pogrebitskiy) Date: Fri, 21 Jul 2006 10:44:53 -0400 Subject: [ftputil] Which Python version(s) do you use? References: <000901c6ac77$50149650$0401a8c0@xurvm> <44C0B26C.9070301@sschwarzer.net> Message-ID: <011c01c6acd4$3acb6410$1f3ff945@valeriya7y577d> Stefan's comment is absolutely correct. There is a second scenario to when dropped support for previous versions will be harmful and will not let people use the product: Some systems (third party products) use Python as an extension language - to allow users develop extensions to the product. I work with one such system, and I am sure there many other products that allow programming in Python, but limit to a certain version only (which comes with the product distribution). So upgrade to a newer Python version sometimes is hard (but possible), and sometimes is just impossible. For example, current version of our product works with Python 2.3.*, but does not work with Python 2.4.* Val. ----- Original Message ----- From: "Stefan Schwarzer" To: Sent: Friday, July 21, 2006 6:54 AM Subject: Re: [ftputil] Which Python version(s) do you use? > Hi Andrew, > > nice to read you again :) > > On 2006-07-21 05:39, Andrew Ittner wrote: >> I second this comment - I use 2.4.2 currently, always try to remain >> within 6 >> months of the latest stable version, and never worry about going >> backwards. >> Yes, please drop support of anything earlier than 2.3. Frankly, even >> going >> with a minimum of 2.4 would be just as good - assuming that makes your >> life >> easier. > > Personally, I would like to go with Python 2.4. I'm inclined to > always use the newest version my Gentoo Linux has as "stable". > > When asking my question I had rather those people in mind which work > for an employer where the IT infrastructure is difficult for them > to influence. For example, such an ftputil user might not be able to > update to a recent Python version without discussing it with the > whole IT department or management. Ok, perhaps such scenarios are > not as frequent as Dilbert cartoons suggest. ;-) > > So now the question doesn't no longer seem to be if ftputil should > require Python 2.2.1, but rather if ftputil should/could require an > even higher version! Python 2.3 or 2.4? ftputil users, speak up! :-) > > Stefan > > _______________________________________________ > ftputil mailing list > ftputil at codespeak.net > http://codespeak.net/mailman/listinfo/ftputil > From danmil at comcast.net Fri Jul 21 18:01:58 2006 From: danmil at comcast.net (Dan Milstein) Date: Fri, 21 Jul 2006 12:01:58 -0400 Subject: [ftputil] Stat'ing a Whole Directory In-Reply-To: <44C00EFA.2060505@sschwarzer.net> References: <44C00EFA.2060505@sschwarzer.net> Message-ID: <50280C82-25D8-4C63-A9B1-92D457866493@comcast.net> Stefan, Thanks for the detailed response. I'll make one more bid for adding something like getfiles (or statdir), and then I'll trundle along on my own ;-) In terms of the performance / making client code solve it / caching: IMHO, caching is at least as nasty from a client perspective as adding a somewhat-redundant method. With caching, the client has to be aware of what the caching state is, and how to flush it, in order to get their code to behave consistently. There are opportunities for the client programmer to make subtle mistakes which fail silently (e.g., in testing everything works fine, but in certain obscure cases, a client call returns an invalid version of a file). Given that you want to keep the current interface (and I say right on ;-), I guess my argument is that adding caching and then exposing methods to flush or keep the cache in sync is not keeping the current interface. And if you're going to change it, adding a comprehensible, non-stateful method feels simpler to me. I'm all for making interfaces hide the complexity of implementations, but, when the implementation involves remote network access, I very much like an extra method or two which allows the client to make their own decisions about performance tradeoffs in a simple way. Just as the DBI interface has fetchone(), fetchmany() and fetchall(). In terms of writing getfiles() using the current interface: I think I didn't explain something clearly enough. The results returned from getfiles() would *not* be simple FTPFiles, because ftp_path.isfoo() can't return information about FTPFiles. They'd be objects which hold both an FTPFile (only opened if it was read from), and also a stat_result. And then ftp_path.isfoo() would have to grow the ability to know what it was passed and handle it intelligently. Which would make ftp_path.isfoo() subtly different from os.path.isfoo (), but in a way which I think people would quickly catch onto. Actually, what I'd do is make FTPFiles behave this way all the time (meaning, they always have or are able to obtain a stat_result). But again, you can do that lazily, and it's hidden from the user. From the user perspective, all they need to learn is: there's a getfiles() method as well as a file() method, and ftp_path methods can operate on both pathnames and FTPFile objects. And then a note on performance says "path.isfoo(path) methods contact the server on every call, consider using getfiles() if you just need file information". Yes, my toy example is easy to replicate with walk(). And there are some important issues with modes and name/path attributes which I haven't fully thought through. Perhaps a better toy example (and this more closely models what I'm doing in my app), would be to display to a user an annotated directory listing of a single directory: for f in host.getfiles(path): if host.path.isdir(f): print "%s (directory)" % f.name elif host.path.islink(f): print "%s (link)" % f.name else: print "%s (size: %s, last_modified: %s)" % (f.name, host.path.getsize(f), host.path.getmtime(f)) You could do this using listdir, but all those calls to host.path.foo () would be deadly. Having a getfiles() method would allow the client code to efficiently do things like: sync an entire tree in both directions; search for files with recent modification dates; list all files over a certain size, etc. Without having to make a remote call for every file in the tree, and without any worries about cache consistency. In general, it gives the client the ability to efficiently obtain and act on completely up-to-date file *information* en masse. And the extra complexity cost to the interface for ftputil is adding one method to ftphost, and overloading the various ftp_path methods. Which, to me, feels like a win. And now, if you still don't want it, I'll stop bugging you ;-) -Dan On Jul 20, 2006, at 7:17 PM, Stefan Schwarzer wrote: > Hi Dan, > > On 2006-07-20 20:39, Dan Milstein wrote: >> c) Low-level/high-lvel >> >> A thought: yes, returning a list of stat results feels a bit low- >> level. Esp since the reason I need the stat results and not just the >> names is to do things like isfile() and isdir(), which I can then >> only do by explicitly calling stat.S_ISDIR(stat_result.st_mode). >> Blech. > > hm, so I currently don't think that this is the way to go. > >> What might be nice, but would move just a bit away from the os.path >> analogy, would be to make ftphost.path be able to run isfile()/isdir >> ()/etc on both path names and also FTPFile objects (or something like >> FTPFile objects -- see below). > > What I would like to avoid is to add an interface that basically > does the same as an already present interface. Look at the > current Python way to get the length of a string: len(s) . A > similar interface, regarding the purpose, might be s.len() . Note > that I don't say that the former way is better, just that there > shouldn't be an _additional_ way if there is already one. > >> If you are interested, what I'd like to do is add a method to >> ftphost: >> >> getfiles(path) > > Should the files be opened in text or binary mode? Should they be > opened for reading or writing? > > At the moment, this could be implemented like this (below), > assuming you want files to be read in binary mode (untested code, > beware): > > def getfiles(path): > files = [] > cwd = host.getcwd() > for name in host.listdir(path): > complete_path = host.path.join(cwd, name) > if host.path.isfile(complete_path): > files.append(host.file(complete_path, 'rb')) > return files > > or, assuming this is a method of `FTPHost`, > > def getfiles(self, path): > files = [] > cwd = self.getcwd() > for name in self.listdir(path): > absolute_path = self.path.join(cwd, name) > if self.path.isfile(absolute_path): > files.append(self.file(absolute_path, 'rb')) > return files > > (I only wrote this code down to see how much effort could be > saved by having the new method. Another criterion is the actual > usefulness.) > >> Which returns a list of FTPFile-like objects (with stat and path >> information hidden in them). They would lazily support the file >> interface, but would only connect to the remote server if someone >> actually reads or writes their contents. And then I would extend >> ftp_path.isdir()/isfile()/etc to handle those objects as well as path >> names. >> >> So that, if you need to operate on a directory, to say, copy all >> files, and recurse over all subdirectories, you could do something >> like: >> >> def copy_all_files(path): >> for f in ftphost.getfiles(path): >> if ftphost.path.isdir(f): >> copy_all_files(f.path) >> else: >> ftphost.copyfileobj(f, file(f.name)) > > The `path` and `name` attributes are a bit tricky. Should `path` > be the absolute path of the file/directory of the server, and > `name` just the tail of the path, similar to what > `os.path.basename(path)` returns? > > If yes, your code iterates recursively through a directory on the > server and copies all the files into a single directory on the > client's local host (actually without closing the files). > > Let me try an alternative implementation which uses the current > `FTPHost` class (again, untested). > > def copy_all_files(host, path): > for dir_path, dir_names, file_names in host.walk(path): > for file_name in file_names: > absolute_path = host.path.join(dir_path, file_name) > host.download(absolute_path, file_name) > >> Which feels fairly clean and intuitive, > > My code feels about as clean and intuitive, I hope. :-) > >> and would behave pretty >> nicely in terms of how it hits the remote server (whereas, with the >> current implementation, the lib is fetching the entire directory >> listing over and over again for every call to isdir()). > > Of course, the _current_ performance isn't good, that's why we > started to discuss caching, after all. However, I would like to > improve the performance _for the current interface_, don't add an > additional interface and let the client deal with the right > interface to improve performance. In that case, the "server" > (ftputil) code is lazy, shifting the responsibility of > optimization to every client (user of ftputil). IMHO, it should > be the other way around: ftputil should improve it's performance > while keeping its interface, thus making it easy for users of the > module. > > Of course, there's a tradeoff: If ftputil doesn't expose the > means for its optimizations, clients have to cope with it; they > won't be able (or not as easily) to fiddle with ftputil to gain > better performance. On the other hand, that's the same kind of > tradeoff when we choose Python (less control, easier to use) over > C (potentially more control, more difficult to use). > > Best wishes > Stefan > _______________________________________________ > ftputil mailing list > ftputil at codespeak.net > http://codespeak.net/mailman/listinfo/ftputil From mgusarov at swsoft.com Wed Jul 26 07:44:15 2006 From: mgusarov at swsoft.com (Mikhail Gusarov) Date: Wed, 26 Jul 2006 12:44:15 +0700 Subject: [ftputil] [BUG] .close() on FTP file may result in exception Message-ID: <87lkqgdiog.fsf@origin.plesk.ru> A non-text attachment was scrubbed... Name: testftputil.py Type: text/x-python Size: 155 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060726/22d400a3/attachment.py From sschwarzer at sschwarzer.net Wed Jul 26 10:34:56 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Wed, 26 Jul 2006 10:34:56 +0200 Subject: [ftputil] [BUG] .close() on FTP file may result in exception In-Reply-To: <87lkqgdiog.fsf@origin.plesk.ru> References: <87lkqgdiog.fsf@origin.plesk.ru> Message-ID: <44C72930.5050807@sschwarzer.net> Hello Mikhail Thanks for your report. (Shouldn't we move it to the bug tracker? Do you want an account?) On 2006-07-26 07:44, Mikhail Gusarov wrote: > If you open file on FTP for reading and close it before reading EOF > (actually, when server still has data to write to data stream), > FTPIOException will be raised, because FTP server will report error > 426. > > Testcase is attached. > > import ftputil > > host = ftputil.FTPHost('debian.nsu.ru', 'anonymous', '') > f = host.file('mirrors/ftp.fi.debian.org/debian/doc/mailing-lists.txt') > f.close() This code doesn't throw an exception here, just as I tried it. RFC 959 [1], which describes the file transfer protocol, discusses the status code 426 like this: """ ABORT (ABOR) This command tells the server to abort the previous FTP service command and any associated transfer of data. The abort command may require "special action", as discussed in the Section on FTP Commands, to force recognition by the server. No action is to be taken if the previous command has been completed (including data transfer). The control connection is not to be closed by the server, but the data connection must be closed. There are two cases for the server upon receipt of this command: (1) the FTP service command was already completed, or (2) the FTP service command is still in progress. In the first case, the server closes the data connection (if it is open) and responds with a 226 reply, indicating that the abort command was successfully processed. In the second case, the server aborts the FTP service in progress and closes the data connection, returning a 426 reply to indicate that the service request terminated abnormally. The server then sends a 226 reply, indicating that the abort command was successfully processed. """ Your's is the second case because the connection is aborted and the status code sent by the server. Which other FTP commands were running or had previously run when the exception occured? It may be a mistake on your side, a server bug, - or in fact a bug in ftputil (e. g. not correctly cleaning up children sessions under certain circumstances, so you run in trouble the _next_ time you use this child [2]). Therefore, I would like to get more information on the context in which the bug appears. Many thanks in advance. :-) [1] http://www.ietf.org/rfc/rfc959.txt [2] Using FTP file-like objects in ftputil creates new FTP sessions behind the scenes. Those sessions are reused after an FTPFile object has been closed. Stefan From sschwarzer at sschwarzer.net Wed Jul 26 12:10:46 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Wed, 26 Jul 2006 12:10:46 +0200 Subject: [ftputil] Which Python version(s) do you use? In-Reply-To: <44C01667.3000903@sschwarzer.net> References: <44C01667.3000903@sschwarzer.net> Message-ID: <44C73FA6.3010103@sschwarzer.net> Hi all, On 2006-07-21 01:48, Stefan Schwarzer wrote: > when I released ftputil for the first time, Python 2.2 had just > been released (or was about to be released). So I tried to make > ftputil compatible with Python versions starting at 2.1, which > required some compromises. I would like to make use of the > features added in 2.2. This would allow to remove e. g. the > UserTuple class and the extra handling of the True/False values > (though they were introduced in Python 2.2.1, not 2.2, if I > remember correctly). > > Thus my question: Which is the lowest Python version you use with > ftputil? Would it be ok to drop compatibility with Python > versions < 2.2.1 with the release of ftputil 2.2? Or do you > really depend on earlier Python versions, i. e. can only switch > to a newer version with much effort? after the discussion we had, I'll try to stick to Python 2.3(.0) as the minimum requirement. I plan to do the changes requiring Python 2.2+ on the same branch which is used to add the stat caching. (This is less "clean" but also much easier to handle than an additional branch.) It may happen that I code something that only works with higher versions (possibly higher minor versions like Python 2.3.3). This is _not_ intentional and should be considered a (usually minor) bug. On the other hand, there may be cases where a particular feature, e. g. in Python 2.3.7 ;-) , is desirable. In this case, we must decide if it's worth to decrease compatibility with older Python versions. Stefan From programer_vedran_d at net.hr Sat Aug 5 19:33:59 2006 From: programer_vedran_d at net.hr (programer_vedran_d) Date: Sat, 05 Aug 2006 19:33:59 +0200 Subject: [ftputil] FTPUTIL PROBLEM Message-ID: <44d4d687.ab.4aa3.1427560692@net.hr> HI,ALL I am new ftputil user and I need help about something:my prog:>>> import tkFileDialog>>> import ftputil>>> name=tkFileDialog.askopenfile()>>>ftp=ftputil.FTPHost() #Please when you want try this proguse your ftp server>>> nesto1=name.name>>> ftp.upload(nesto1,nesto1,'b')ERROR IS:Traceback (most recent call last): File "", line 1, in -toplevel- ftp.upload(nesto1,nesto1,'b') File "C:\Python24\lib\ftputil.py", line 463, in upload self.__copy_file(source, target, mode, open, self.file) File "C:\Python24\lib\ftputil.py", line 452, in__copy_file target target_mode) File "C:\Python24\lib\ftputil.py", line 282, in file raise ftp_error.FTPIOError("directory '%s' is notaccessible" %FTPIOError: directory '/C:/Python24' is not accessible THANKS!!!!!!!!!!!!!! -- Odaberite XXLadsl - od sada 2 x br?i uz iste cijene priklju?ka i paketa! Vi?e saznajte na http://www.iskon.biz/xxladsl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060805/01ef8fef/attachment.htm From knixon at zooandaquarium.com Mon Aug 7 08:08:46 2006 From: knixon at zooandaquarium.com (Katharine Nixon) Date: Mon, 07 Aug 2006 02:08:46 -0400 Subject: [ftputil] Microcap Communiqu?Investor Communiqu?Stealth Microcap Message-ID: <1154930926.69476@zooandaquarium.com> An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060807/a5678015/attachment.htm From sschwarzer at sschwarzer.net Mon Aug 7 15:20:03 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Mon, 07 Aug 2006 15:20:03 +0200 Subject: [ftputil] FTPUTIL PROBLEM In-Reply-To: <44d4d687.ab.4aa3.1427560692@net.hr> References: <44d4d687.ab.4aa3.1427560692@net.hr> Message-ID: <44D73E03.9010302@sschwarzer.net> Hi :) (Your mail arrived badly formatted; the line breaks in your original code and the traceback were missing. It seems that your mail client is broken; you may speak to the provider of the web mail service you use. I reformatted your text.) > I am new ftputil user and I need help about something: > > my prog: > > >>> import tkFileDialog > >>> import ftputil > >>> name=tkFileDialog.askopenfile() > >>> ftp=ftputil.FTPHost() #Please when you want try this prog use your ftp server > >>> nesto1=name.name > >>> ftp.upload(nesto1,nesto1,'b') > > ERROR IS: > Traceback (most recent call last): > File "", line 1, in -toplevel- > ftp.upload(nesto1,nesto1,'b') > File "C:\Python24\lib\ftputil.py", line 463, in upload > self.__copy_file(source, target, mode, open, self.file) > File "C:\Python24\lib\ftputil.py", line 452, in__copy_file > target = target_open(target, target_mode) > File "C:\Python24\lib\ftputil.py", line 282, in file > raise ftp_error.FTPIOError("directory '%s' is notaccessible" %FTPIOError: directory '/C:/Python24' is not accessible You try to use exactly the same file name (including path, that including drive letter) for the source and the target file. Since the directory "/C:/Python24" probably isn't on the server, ftputil complains that the directory isn't accessible. The error message is correct, but it should maybe tell that the directory might not exist at all. Assuming you want to select a local file and upload it to the current directory on the server, you should replace your code ftp.upload(nesto1,nesto1,'b') with import os ... ftp.upload(nesto1, os.path.basename(nesto1), 'b') On using os.path.basename vs. ftp.path.basename: The argument string is the name, including path, of a local file, so the function for a local file system (i. e. os.path.basename) should be used to remove the drive letter and the directory part. Does this help? :-) Stefan From sschwarzer at sschwarzer.net Mon Aug 7 15:37:05 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Mon, 07 Aug 2006 15:37:05 +0200 Subject: [ftputil] Error message for inaccessible directory (was: Re: FTPUTIL PROBLEM) In-Reply-To: <44D73E03.9010302@sschwarzer.net> References: <44d4d687.ab.4aa3.1427560692@net.hr> <44D73E03.9010302@sschwarzer.net> Message-ID: <44D74201.3080105@sschwarzer.net> Hi all, On 2006-08-07 15:20, Stefan Schwarzer wrote: > You try to use exactly the same file name (including path, that > including drive letter) for the source and the target file. Since > the directory "/C:/Python24" probably isn't on the server, ftputil > complains that the directory isn't accessible. The error message > is correct, but it should maybe tell that the directory might not > exist at all. I've just checked in change 547 on the trunk, see http://ftputil.sschwarzer.net/trac/changeset/547 . The new error message is "directory '%s' doesn't exist or has insufficient access rights". I hope, I haven't excluded other possible causes. Have I? Can you think of one? Stefan From sschwarzer at sschwarzer.net Sat Aug 19 13:55:27 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Sat, 19 Aug 2006 13:55:27 +0200 Subject: [ftputil] [ANN] ftputil 2.1.1 released Message-ID: <44E6FC2F.1000103@sschwarzer.net> Hello! ftputil 2.1.1 is now available from http://ftputil.sschwarzer.net/download . This release fixes a bug which happened when a client opened a large file on the server as a file-like object and read only a part of it. For details, see http://ftputil.sschwarzer.net/trac/ticket/17 . Stefan From vedran500 at net.hr Sun Aug 20 20:59:24 2006 From: vedran500 at net.hr (vedran500) Date: Sun, 20 Aug 2006 20:59:24 +0200 Subject: [ftputil] ftputil except problem Message-ID: <44e8b10c.34d.7212.1748621598@net.hr> Hi, I have one strange ftputil problem, example of my program: (I was give wrong informations about ftp server,becose I want to my program "skip" error) >>> import ftp_error >>> import ftputil >>> import tkMessageBox >>> try: ftp=ftputil.FTPHost('vedran.byethost12.com','vedran at vedran.byethost12.com','veti') except ftp_error.PermanentError: SyntaxError: invalid syntax Regards, Vedran,Croatia -- Odaberite XXLadsl - od sada 2 x br?i uz iste cijene priklju?ka i paketa! Vi?e saznajte na http://www.iskon.biz/xxladsl From sschwarzer at sschwarzer.net Mon Aug 21 16:50:29 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Mon, 21 Aug 2006 16:50:29 +0200 Subject: [ftputil] ftputil except problem In-Reply-To: <44e8b10c.34d.7212.1748621598@net.hr> References: <44e8b10c.34d.7212.1748621598@net.hr> Message-ID: <44E9C835.304@sschwarzer.net> Hello Vedran, On 2006-08-20 20:59, vedran500 wrote: > I have one strange ftputil problem, > > example of my program: > > (I was give wrong informations about ftp server,becose I want to my program "skip" error) > >>>> import ftp_error >>>> import ftputil >>>> import tkMessageBox >>>> try: > ftp=ftputil.FTPHost('vedran.byethost12.com','vedran at vedran.byethost12.com','veti') > except ftp_error.PermanentError: > > SyntaxError: invalid syntax unless you get a SyntaxError in one of the distributed ftputil files, a SyntaxError should never have anything to do with ftputil. Possibly you have accidentically used a mixture of tab and space characters for the indentation of your code. Always(*) use four spaces per indentation level, never tabs. The script tabnanny may help you to find inconsistent indentation (see http://docs.python.org/lib/module-tabnanny.html ). Hope that helps. (*) unless you have to work with a project's code which is consistently tab-indented (there are few such projects), and even then you should use spaces in your own files which don't belong to the "tabbed project" Stefan From vedran500 at net.hr Sat Aug 26 16:34:09 2006 From: vedran500 at net.hr (vedran500) Date: Sat, 26 Aug 2006 16:34:09 +0200 Subject: [ftputil] ftputil question Message-ID: <44f05be1.1f2.911.361017651@net.hr> Hi, I just have one question.Have ftputil SSL or other protections Regards, Vedran,Croatia -- Odaberite XXLadsl - od sada 2 x br?i uz iste cijene priklju?ka i paketa! Vi?e saznajte na http://www.iskon.biz/xxladsl From sschwarzer at sschwarzer.net Sat Aug 26 18:06:33 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Sat, 26 Aug 2006 18:06:33 +0200 Subject: [ftputil] ftputil question In-Reply-To: <44f05be1.1f2.911.361017651@net.hr> References: <44f05be1.1f2.911.361017651@net.hr> Message-ID: <44F07189.8070404@sschwarzer.net> Hi Vedran, On 2006-08-26 16:34, vedran500 wrote: > I just have one question.Have ftputil SSL or other protections ftputil has no built-in SSL support. On the other hand, you can use M2Crypto [1] which has a class derived from ftplib.FTP that supports SSL. You then can use this class (not an object of it) as a "session factory" in ftputil.FTPHost's constructor. See [2] and [3] for similar code. [1] http://sandbox.rulemaker.net/ngps/m2/ ; in the archive, look for the file M2Crypto/ftpslib.py [2] http://ftputil.sschwarzer.net/trac/wiki/Documentation#connecting-on-another-port [3] http://ftputil.sschwarzer.net/trac/wiki/Documentation#using-active-or-passive-connections HTH :) Stefan P.S.: Note to myself: Include the question and answer in the FAQ. :-) From swansonidazh at amtrol.com Wed Aug 30 14:34:22 2006 From: swansonidazh at amtrol.com (Demeter Byers) Date: Wed, 30 Aug 2006 05:34:22 -0700 Subject: [ftputil] toRXny Message-ID: <000001c6cc30$9f3d9eb0$c864a8c0@auvhv> Hi, http://yunhadewiondefase.com , l , s , j teeth grating as I spoke. complex, as you know. There vas, however . . . he began to sweat, apparatus in its center. Fido dropped its bit of debris, lifted one -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060830/baf4f10c/attachment.htm From metaperl at gmail.com Sun Sep 3 02:52:37 2006 From: metaperl at gmail.com (Terrence Brannon) Date: Sat, 2 Sep 2006 20:52:37 -0400 Subject: [ftputil] debug mode? Message-ID: Hi, I looked through the docs for ftputil but did not see any mention of a way to get the details of FTP interaction. set_debuglevel did not work. Thanks, Terrence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060902/fb2f41a1/attachment.htm From jlxbtw at levillagedemusher.com Sun Sep 3 05:35:29 2006 From: jlxbtw at levillagedemusher.com (BullsEye) Date: Sun, 3 Sep 2006 00:35:29 -0300 Subject: [ftputil] BullsEye September Issue: TMXO (STRONG BUY) Message-ID: <002501c6cf0b$052e7b63$79de7bc8@hjzp.ezljrx> BullsEye Financial Weekly Report September Issue: Make no mistake, our mission at BullsEye Financial is to sift through the thousands of underperforming companies out there to find the golden needle in the haystack. The micro-cap diamond that can make you a fortune. More often than not, the stocks we profile show a significant increase in stock price, sometimes in days or hours, not months or years. We have come across what we feel is one of those rare deals that the public has not heard about yet. Trade Date: Tuesday, September 5, 2006 Company : TRIMAX CORPORATION (OTC BB:TMXO.OB) Ticker : TMXO Current Price : $0.38 Short Term Target Price : $1.50 Long Term Target Price : $2.50 Recommendation: STRONG BUY Brokers and Day-Traders are gonna be scrambling Tuesday Morning. Don't let them beat you to the punch, get in EARLY on Tuesday morning!!! We all know that in the this business it's the big announcements that makes these explode! From sschwarzer at sschwarzer.net Wed Sep 6 00:02:12 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Wed, 06 Sep 2006 00:02:12 +0200 Subject: [ftputil] debug mode? In-Reply-To: References: Message-ID: <44FDF3E4.2060007@sschwarzer.net> Hi Terrence, On 2006-09-03 02:52, Terrence Brannon wrote: > Hi, I looked through the docs for ftputil but did not see any mention of a > way to get the details of FTP interaction. > > set_debuglevel did not work. The ftputil.FTPHost class per default uses the ftplib.FTP class to work with FTP connections. FTPHost doesn't have a debugging switch (at least not yet; send me a user name and password for an account on ftputil.sschwarzer.net to enter an issue in the tracker if you want). But you can use the recipes at http://ftputil.sschwarzer.net/trac/wiki/Documentation#connecting-on-another-port and http://ftputil.sschwarzer.net/trac/wiki/Documentation#using-active-or-passive-connections to come up with a similar recipe to set the debug option of contained ftplib.FTP objects. Stefan From gat at mortalino.ch Wed Aug 30 09:19:24 2006 From: gat at mortalino.ch (Donald Jacobs) Date: Wed, 30 Aug 2006 10:19:24 +0300 Subject: [ftputil] ringleader Message-ID: <000701c6cc05$426f21f7$572e6255@quufvd.lp> But on the table beforeher lay a brand-new Jimmy-book. Once she would have poured it into a letter toher father. Allan Burnley came to New Moon at sunset, on his way home fromtown. She was terrified by the childs condition. Emily sat up in bed and looked at Aunt Laura again. It isnt so much of a jobto put ladders in the well and get some one to go down it. The sensationcaused by Dr Burnleys presence every Sunday in the old Burnley pewhad died away. Laura was trying to soothe Emily, who was struggling to sit up inbed. Aunt Elizabeth,she suddenly turned and caught Aunt Elizabeths hand, youll do itfor me, wont you? She wished shehad never given her verses to Mr Carpenter. I think Ive always known it, said Emily dreamily. He is smiling with his eyes as well as his mouth now, thoughtEmily. All characters are, of course, directly transcribed from life. It can be explained rationally enough perhaps. Our stepmothers mother was a Highland Scotchwoman. We wont talk of it again, said Aunt Laura gently. It alsotells you how you may distribute copies of this eBook if you want to. Of course, Ilseis dying to come and see you, Emily. They said shehad the second sight, said Elizabeth. Shemight as well have measles and be done with it. Emily fell into a troubled slumber which lasted until thegrey dawn crept into the lookout. But Mr Carpenter had tossed June aside without reading a line ofit. Thanks to her dramatic knack of word painting, MrCarpenter LIVED in that sketch. That flash ofunimaginable sweetness that sometimes surprised her had just comeand gone. The sensationcaused by Dr Burnleys presence every Sunday in the old Burnley pewhad died away. MrCarpenter watched her out of sight from the old worn threshold. Perry, Ilse and Teddy hadall come down with measles the same day. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060830/b339c3e4/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 16203 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060830/b339c3e4/attachment-0001.gif From unbe at 24times7.com Mon Sep 11 00:09:32 2006 From: unbe at 24times7.com (Henry Santiago) Date: Mon, 11 Sep 2006 01:09:32 +0300 Subject: [ftputil] perennial weirdo Message-ID: <001b01c6d526$633ca4de$8a6fdac4@qn.dehw> As it happened, Bobby had come in just when Niels was punishingher. The whole marriage, the whole antecedents of this marriage wereimmoral . It was not often that Niels even saw his wife in the early part ofthe winter. Unlike dogs, they do not cling to or fawnupon him who does not deserve their love. Atlast he turned north again, along pig-pens and milk-house, till hereached the garden. Pictures of the past flitted throughhis mind: the first that had come to him through many months. A feeling of shame swept through him,unnerving his strength. There heturned south into the bush, almost running over the sun-dappledsoil between the trees. It would almost seem as if she watched for his appearance on theyard to extinguish even her lamp. It was a meeting of no more than a quarter minute. Hopelessness andindifference began to show more and more even in his physique. Suddenly the shadow of a figure fell across the grass in front ofhim. It was still early when he saw his wife leave the house for her nowaccustomed walk in the bluff. As for the farm, he would pay in half crops. But he attended himself to all those of thechores which necessitated entering the house. Again she was in undress for the night, with a gown thrown over hershoulders. When he came to the sentence, That which is crooked cannot be madestraight, it seemed a comfort. And yet, Niels, even then I could not get rid of the thought ofyou. On the wagon-truck drawn by the slow, plodding beasts rested asand-box without a seat. The manbent over and kissed her on the mouth, long, fervently, with thekiss of a sensual lover. Suddenly his heart began to beat like a sledgehammer; he could hearits thud. Im two rounds ahead, Niels said as he let himself down from hisseat. If he avoided people in thissettlement, the people also avoided him. How could he, how could he let things getthe better of him that way? Niels first impulse had been to go to her aid. Suppose he had simulated feelings which he did not have . He had strongly, forcibly realised that he was not the onlysufferer. Thealarm clock showed a quarter past nine . Unlike dogs, they do not cling to or fawnupon him who does not deserve their love. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060911/2ac3ff9e/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13771 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060911/2ac3ff9e/attachment.gif From iwcook58 at gmail.com Thu Sep 14 23:47:22 2006 From: iwcook58 at gmail.com (Ian Cook) Date: Fri, 15 Sep 2006 05:47:22 +0800 Subject: [ftputil] FtpUtil Progress Bar Message-ID: <002e01c6d847$603743b0$8702010a@iandesktop> Hi I am new to this list so please excuse me if this has been asked before. I can successfully upload and download files using Stefan's Schwarzer's terrific ftputil script. The problem is that as some of the files are quite large you cannot see how much has been downloaded/uploaded. Even a percentage or just dots going across the screen would be better than nothing. Does anyone have an example on how to show the progress of the upload/download when using ftputil? Thanks in advance. Kind regards Ian Cook -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060915/3966acf6/attachment.htm From valeriy.pogrebitskiy at db.com Fri Sep 15 13:39:40 2006 From: valeriy.pogrebitskiy at db.com (Valeriy Pogrebitskiy) Date: Fri, 15 Sep 2006 07:39:40 -0400 Subject: [ftputil] FtpUtil Progress Bar In-Reply-To: <002e01c6d847$603743b0$8702010a@iandesktop> Message-ID: This module is not intended as a command line utility (like standard 'ftp')... It is intended to be used within other Python programs through the means of function calls. As such, completion of a file upload/download is indicated by a return from corresponding function call. What else would you need? Intermediate output would be undesirable - as it would mean unexpected output within other programs. On the other hand - if Stefan's library does have internal ways of keeping track of process's progression - then you could write your own command line utility to display dots or percentages... Valeriy Pogrebitskiy | Vice President | DBARS (O) 908-608-3131 | (E) vpogrebi at iname.com "Ian Cook" Sent by: ftputil-bounces at codespeak.net 09/14/2006 05:47 PM To cc Subject [ftputil] FtpUtil Progress Bar Hi I am new to this list so please excuse me if this has been asked before. I can successfully upload and download files using Stefan's Schwarzer's terrific ftputil script. The problem is that as some of the files are quite large you cannot see how much has been downloaded/uploaded. Even a percentage or just dots going across the screen would be better than nothing. Does anyone have an example on how to show the progress of the upload/download when using ftputil? Thanks in advance. Kind regards Ian Cook _______________________________________________ ftputil mailing list ftputil at codespeak.net http://codespeak.net/mailman/listinfo/ftputil -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060915/70fa7f11/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2596 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060915/70fa7f11/attachment-0001.gif From sschwarzer at sschwarzer.net Fri Sep 15 14:11:47 2006 From: sschwarzer at sschwarzer.net (Stefan Schwarzer) Date: Fri, 15 Sep 2006 14:11:47 +0200 Subject: [ftputil] FtpUtil Progress Bar In-Reply-To: References: Message-ID: <450A9883.2070401@sschwarzer.net> Hi Valeriy and Ian, On 2006-09-15 13:39, Valeriy Pogrebitskiy wrote: > This module is not intended as a command line utility (like standard > 'ftp')... It is intended to be used within other Python programs through > the means of function calls. As such, completion of a file upload/download > is indicated by a return from corresponding function call. What else would > you need? Intermediate output would be undesirable - as it would > mean unexpected output within other programs. Ok, ftputil isn't a command line utility. But it may be used to write them. ;-) I remember someone asking for a "feedback" feature in upload_if_newer and download_if_newer to indicate whether a file was uploaded/ downloaded or not. Since then the two methods return a corresponding boolean value. In a similar spirit, I could possibly add a callback parameter to the upload/download methods, but to be consistent it should go with the conditional versions, too, shouldn't it? > On the other hand - if Stefan's library does have internal ways of keeping > track of process's progression - then you could write your own command > line utility to display dots or percentages... This might be another way to tackle the problem but as I understand this would mean to add a "state query" component which may be overkill. Ian, _how_ important is the feature for you? "Nice to have" or it is really annoying for your users to miss the progress (i. e. large files or slow connections)? In any case, you can file an issue from http://ftputil.sschwarzer.net/trac/wiki/IssueTracker . If you want to, send me a mail and I'll add an account for you. (Anonymous tickets are disabled due to to spam.) Stefan From blaarhea at bdsonline.com Sun Sep 17 06:36:11 2006 From: blaarhea at bdsonline.com (Hjo Wolpert) Date: Sat, 16 Sep 2006 21:36:11 -0700 Subject: [ftputil] my PHefpARMA Message-ID: <01c6da14$5abc2a80$037ba8c0@homeycxa2b1khu> Hi QU t IT O s VERP o AYIN w G FOR YOU s R P w HAR p MAC v Y S d AV z E u j p to 6 e 0 % wi w th http://www.basdunjefinkasxa.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060916/648c2436/attachment.htm From 01consoon at zotti.com Thu Sep 21 16:31:42 2006 From: 01consoon at zotti.com (Floyd Gilliam) Date: Thu, 21 Sep 2006 13:11:42 -0120 Subject: [ftputil] THURSDAY.kb Message-ID: <01c6dd7f$7afa7fe0$6c822ecf@01consoon> HOT {stock_r} !!! - THIS ONE IS STILL CLIMBING THE STOCK CHARTS !!!! ALERT -- BREAKING MARKET NEWS REPORT !!! ---- HBID.PK Here is my {fav_r} {pick_r} for the second half of 2006: HBID!!! Company Name: HOT BRANDS INC (HBID) Lookup: HBID Current Price: $0.35 Target Price: $1.27 Recommendation: 'STRON GBUY' Expectations: Max WATCH THIS {stock_r}GO HIGHER AND HIGHER DON'T MISS THIS INVESTMENT MOMENT, PLACE HBID ON THE RADAR!!! Breaking News: Gold & Silver Minerals (PINKSHEETS: HBID), a Nevada {com_r} trading as Hot Brands, Inc., today announced that it has retained an experienced geologist to prepare an evaluation of a mineral property offered to the Company. The evaluation will be detailed in a format similar to that of the National Instrument 43-101 Technical Report common in the industry. National Instrument 43-101 provides strict standards of disclosure for mineral projects. A NI43-101 report is written usually by a geologist or mining engineer, who has experience in valuing mineral deposits and mining projects. We expect the report to be completed and available mid-September. The property in question is a 40-acre Mineral Estate located in Churchill County, Nevada. Past analyses of exploration and development samples have suggested the possibility of detectable amounts of gold, silver, platinum and rhodium. AS GOLD AND SILVER PRICES GET READY TO {rise_r}, SO DOES HBID!!! TRADE {smart_r} AND WIN WITH HBID!!!! About Gold & Silver Minerals Gold & Silver Minerals is an emerging exploration and mining company that focuses on acquiring assets and growing a revenue base in the area of production and exploration of minerals. Areas of interest include precious metals, industrial minerals and other natural resources. We believe that these sectors hold the most promise for market interest, asset growth and near-term cash flow, with underlying fundamentals that provide an outlook for stable to growing product prices. DON'T EVEN {miss_r}! HBID DOESN'T SLEEP IT WILL {epl_r} ON THURSDAY, SEPTEMBER 21,2006!!! ADD THIS GEM TO YOUR RADAR AND {pla_r} IT TO YOUR INVESTMENT PORTFOLIO!!!! From 648consoon at zorstec.com Fri Sep 22 01:53:17 2006 From: 648consoon at zorstec.com (Irma Rangel) Date: Fri, 22 Sep 2006 02:53:17 +0300 Subject: [ftputil] nuclear ambitions 1 Message-ID: <126503026.17559921973807@thebat.net> , and how to exploit same problems. In a way that makes you Java's built-in pattern is so often misunderstood, Patterns--the lessons In a way that lets you put you don't want to when to use them, how learned by those matter--why to use them, in between sips of a martini. of Design Patterns so how patterns are be wrong (and what his stunningly clever use of Command, reinvent the wheel to know how they used in the Java API in between sips of a martini. Facade, Proxy, and Factory you have. You know with the latest research in to use them (and when , and how to exploit Java's built-in pattern and experience of others, In a way that makes you to use them (and when between Decorator, Facade to do instead). You want a book, you want a book, you want it struggling with academic Head First book, you know brain in a way that sticks. you want to learn the learned by those and Adapter. With Head First is so often misunderstood, You'll easily counter with your look "in the wild". on your team. between Decorator, Facade same problems. of patterns with others "secret language" , and how to exploit Head First Design Patterns texts. If you've read a on your team. your time on...something on your team. challenging. Something be wrong (and what them to work immediately. You want to learn about Singleton isn't as simple as it in between sips of a martini. your boss told you want to see how But you don't just them to work immediately. them to work immediately. texts. If you've read a In their native Singleton isn't as simple as it put you to sleep! We think reinvent the wheel (and impress cocktail party guests) will load patterns into your that you can hold your of the best practices look "in the wild". You want to learn about Design Patterns, you'll avoid You're not to learn how those Facade, Proxy, and Factory also want to learn Best of all, in a way that won't In a way that lets you put and experience of others, own with your co-worker patterns look in Design Patterns, you'll avoid applications. You Most importantly, his stunningly clever use of Command, in between sips of a martini. design problems what to expect--a visually-rich your boss told you Something more fun. in between sips of a martini. how patterns are format designed for the way you don't want to Decorator is something from words, in real world of the best practices to learn how those With Design Patterns, who've faced the on your team. you want to learn the better at solving software when he casually mentions when to use them, how better at solving software your boss told you Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060922/09f768b9/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9767 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060922/09f768b9/attachment-0001.png From 7528consoon at zootoyou.com Fri Sep 22 19:18:43 2006 From: 7528consoon at zootoyou.com (Rosanna Leach) Date: Fri, 22 Sep 2006 17:18:43 0000 Subject: [ftputil] in the Middle East by 1 Message-ID: <123031202.00687467430750@thebat.net> to learn how those you get to take matter--why to use them, neurobiology, cognitive Head First book, you know it struggling with academic Most importantly, what to expect--a visually-rich a book, you want to do instead). You want want to see how your time is too important of patterns with others applications. You your boss told you sounds, how the Factory Singleton isn't as simple as it Something more fun. between Decorator, Facade design problems, and better You want to learn the learned by those you have. You know science, and learning theory, You want to learn about In a way that makes you you want to learn the when he casually mentions his stunningly clever use of Command, neurobiology, cognitive advantage (or worse, a flat tire), design problems (or worse, a flat tire), Decorator is something from of patterns with others You're not In their native to learn how those In their native Facade, Proxy, and Factory with You want to learn the "secret language" support in your own code. deep understanding of why more complex. put you to sleep! We think neurobiology, cognitive a book, you want (and impress cocktail party guests) challenging. Something principles will help what to expect--a visually-rich you want to learn the it struggling with academic so that you can spend (and impress cocktail party guests) with patterns look in science, and learning theory, so you look to Design of patterns with others Patterns--the lessons Head First Design Patterns you have. You know of patterns with others NOT to use them). on your team. and experience of others, up a creek without your time is too important with what to expect--a visually-rich NOT to use them). texts. If you've read a words, in real world principles will help else. Something more you want to learn the to learn how those Head First Design Patterns words, in real world same problems. You'll easily counter with your in between sips of a martini. advantage Head First book, you know when to use them, how In a way that lets you put neurobiology, cognitive with texts. If you've read a so that you can spend same problems. be wrong (and what is so often misunderstood, and why everything of Design Patterns so words, in real world brain in a way that sticks. is so often misunderstood, alone. At any given moment, better at solving software look "in the wild". when to use them, how Facade, Proxy, and Factory NOT to use them). Java's built-in pattern Best of all, in a way that won't matter--why to use them, sounds, how the Factory Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y>Y> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060922/2f0d63e7/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 9783 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060922/2f0d63e7/attachment.png From xbf at versanet.de Tue Sep 26 15:36:39 2006 From: xbf at versanet.de (Felicia Howell) Date: Tue, 26 Sep 2006 15:36:39 +0200 Subject: [ftputil] offing accountability Message-ID: <001901c6e171$7b6d6a50$8a698753@hid> Housley With new technologies, algorithms and sources emerging on a daily basis, webmasters are constantly struggling to stay informed. Writing articles for the benefit of your target market, and placing them on ezines related to your products can form a formidable promotional strategy. DVD media will soon become what CD media is now. Alerts and instant notifications can be instrumental in monitoring search engine position, trademarked terms, monitoring competitors and staying abreast of online o. Without Undelete facility, restoring these files means a time-consuming, expensive restoration from tape backup. Internet marketers are constantly concerned with this question how to get more visit. DVD media will soon become what CD media is now. " Digital products are any products that you buy and then download to your computer or print to paper. " Digital products are any products that you buy and then download to your computer or print to paper. And marketers see it as low on cost and high in effectiveness. We work and work, market and market and cannot figure out why our mailboxes are not just overloaded with orders. Now to grow your busine. Can we beat the "ants in the pants" people? Without Undelete facility, restoring these files means a time-consuming, expensive restoration from tape backup. It helps that he has never met a reporter whose phone calls he will not return. To capture a larger market share and be viable, sustainable and profitable, you absolutely need to differentiate or dist. In the name of "marketing," business owners are providing way too much information for free. Heck, many well known marketers have started their fortunes b. workers, she explained. cell subscribers pay for both outgoing and incoming. You had successfully entered the realm of the info. Without Undelete facility, restoring these files means a time-consuming, expensive restoration from tape backup. Before we can answer, you must understand what "success" means and what common characteristics successful people have. DVD media will soon become what CD media is now. Many of us squirm and struggle with the answer. In the name of "marketing," business owners are providing way too much information for free. But these and similar reasons is not what causes your lack . Remember this: when s. Unless you were super lucky you can relate to this feeling. Even though he has denigrated the billions spent on airport security as almost entirely wasted, the Transportation Security Administration asked him for advice about its passenger-screening program. Your affiliate links are your business; you are the owner of a marketing company, and it is an asset you can grow into more . The goal of creating a site that can be quickly found . Most phishers have gotten. A mentor provides a service. Members of The Internet Marketing Warriors may change the Warrior Pro url, in the last paragraph of the article to their Warrior referral url. Thus defined, mentoring has been a business practice for a long time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060926/ca16681e/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 9164 bytes Desc: not available Url : http://codespeak.net/pipermail/ftputil/attachments/20060926/ca16681e/attachment-0001.gif From gergobreen at abacocharters.com Thu Sep 28 22:39:17 2006 From: gergobreen at abacocharters.com (Joey Zambrano) Date: Thu, 28 Sep 2006 21:39:17 +0100 Subject: [ftputil] new PHAwkhRMA Message-ID: <01c6e335$c94daa80$0301a8c0@kamiljaww8djhy> Good day, CIeALIS AMeBIEN VIeAGRA VAeLIUM Economize 50 % http://www.buhertionkadesinla.com _____ stopped and the sun was burning through and raising trails of mist Then why was I so depressed? I know a lot more than that, he said pressing the beard and -------------- next part -------------- An HTML attachment was scrubbed... URL: http://codespeak.net/pipermail/ftputil/attachments/20060928/c581dbda/attachment.htm