[ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable.
Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable.
Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by mozbugbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. -- >Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable.
Bugs item #1357260, was opened at 2005-11-15 20:35 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. -- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? -- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 21:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1357604 ] os.path.makedirs DOES handle UNC paths
Bugs item #1357604, was opened at 2005-11-15 20:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.makedirs DOES handle UNC paths Initial Comment: File: http://www.python.org/doc/current/lib/os-file-dir.html Paragraph: """ makedirs( path[, mode]) Recursive directory creation function. Like mkdir(), but makes all intermediate-level directories needed to contain the leaf directory. Throws an error exception if the leaf directory already exists or cannot be created. The default mode is 0777 (octal). This function does not properly handle UNC paths (only relevant on Windows systems; Universal Naming Convention paths are those that use the `\host\path' syntax). New in version 1.5.2. """ I just os.path.makedirs(...) with a UNC path and it DID create the desired folder on the specified host. The "in development" documentation is the same as the above documentation. I did not see any reference to this in the existing documentation bug reports. My particulars ... Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Windows XP-pro (all latest patches) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1063937 ] Random core dumps
Bugs item #1063937, was opened at 2004-11-10 10:50 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: munder12 (munder12) Assigned to: Neal Norwitz (nnorwitz) Summary: Random core dumps Initial Comment: I have narrowed it down as far as I can by continuing to make the problem simpler and simpler but where it still core dumps. The way this is set up is the following: pytest2.py and pytest.py are in the same directory. pytest3.py is in PYTHONPATH where PYTHONPATH is /BASE:/SUP (pytest3.py is in BASE). Run ./pytest2.py several times. This current problem core dumps on average about 2 times every 5 runs. I have attached a file that has the Python listings as well as the gdb traceback. This is running under Fedora Core 1 with: Python 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Thank you, Mark PS Strangely enough the comments in pytest.py seem to actually increase the frequency of core dumps. -- >Comment By: munder12 (munder12) Date: 2005-11-15 18:09 Message: Logged In: YES user_id=1156202 I'm no longer on Fedora Core 1 and cannot tell if this has been fixed on that system or not. I do not have the problem on Fedora Core 3. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 00:55 Message: Logged In: YES user_id=33168 munder12, if you are still having problems let us know. I'm closing this as not reproducible. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 04:15 Message: Logged In: YES user_id=1188172 I'd say that it can be closed. As mwh says: "If Python 2.4b2 cored 25% of the time it was launched, someone else would have noticed by now :)" -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 01:42 Message: Logged In: YES user_id=33168 I can't reproduce on current CVS (2.5). Can anyone reproduce this now? Should this be closed? -- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-23 03:15 Message: Logged In: YES user_id=1038590 I'm not sure it's relevant, but I once had a similar problem with Python flakiness that turned out to be due to some old .pyc files lying around (this was Fedora Core 3-test 1, and the offending files were in my Python CVS build directory). For whatever reason, Python wasn't picking up the version mismatch and was trying to use the old .pyc files. Seg faults abounded as a result. One thought: could root ownership of pre-generated .pyc's have that effect? (I don't know how Python reacts if it can't delete the .pyc's) -- Comment By: munder12 (munder12) Date: 2004-11-17 11:00 Message: Logged In: YES user_id=1156202 I have written a program in C that just opens and closes a file repeatedly. It appears to work fine. But, there appears to be much more that Python is doing behind the scenes than what my script is explicitly directing (open and close the file). Since I'm not sure what all OS related calls Python is making when opening, say, "site.py," I'm not quite sure how I can write a C code that mimics what Python is doing. It may well be that the OS is the culprit. However, it also could be that, in the Python code itself, some error checking is not being performed on all OS calls as they should be since they so rarely fail on a mjority of OS's. Or, extra try...catch blocks maybe could be added to retry the OS call(s) that is "incorrectly" failing on Fedora Core 1 so that Python maintains its portability with (hopefully) minimal speed impact. -- Comment By: Tim Peters (tim_one) Date: 2004-11-16 18:54 Message: Logged In: YES user_id=31435 At this point, it would be prudent to write the same kind of program in straight C, and test that. The more you find out, the less it appears that Python has something to do with what you're seeing. Note that it's not unusual to discover OS, compiler, and platform C library bugs by running Python programs, simply because Python builds on all of them. -- Comment By: munder12 (munder12) Date: 2004-11-16 18:47 Message: Logged In: YES user_id=1156202 It is 2 times out of 8 runs of the
