Skip to content

importing from UNC roots doesn't work #47927

Closed
Closed
importing from UNC roots doesn't work#47927
Labels
OS-windowsinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

Description

@kristjanvalur
kristjanvalur
mannequin
opened on Aug 25, 2008
BPO 3677
Nosy @loewis, @kristjanvalur, @benjaminp
Files
  • not_use_stat_in_import_on_windows.patch: trunk
  • not_use_stat_in_import_on_windows.patch: reviewed by Kristjan, fixes this issue and
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2009-01-09.20:11:28.215>
created_at = <Date 2008-08-25.15:00:26.607>
labels = ['interpreter-core', 'type-bug', 'OS-windows']
title = "importing from UNC roots doesn't work"
updated_at = <Date 2009-01-24.13:57:44.811>
user = 'https://github.com/kristjanvalur'

    bugs.python.org fields:

    activity = <Date 2009-01-24.13:57:44.811>
actor = 'ocean-city'
assignee = 'none'
closed = True
closed_date = <Date 2009-01-09.20:11:28.215>
closer = 'kristjan.jonsson'
components = ['Interpreter Core', 'Windows']
creation = <Date 2008-08-25.15:00:26.607>
creator = 'kristjan.jonsson'
dependencies = []
files = ['11740', '12591']
hgrepos = []
issue_num = 3677
keywords = ['patch']
message_count = 19.0
messages = ['71932', '71941', '74478', '74490', '74491', '74495', '74496', '74500', '74501', '79118', '79500', '80397', '80399', '80434', '80442', '80443', '80444', '80446', '80448']
nosy_count = 5.0
nosy_names = ['loewis', 'ggenellina', 'kristjan.jonsson', 'ocean-city', 'benjamin.peterson']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3677'
versions = ['Python 2.5']

    Activity

    1. kristjanvalur commented on Aug 25, 2008

      @kristjanvalur
      kristjanvalurmannequin
      on Aug 25, 2008
      MannequinAuthor

      When executing a script from a UNC path, e.g. //myhost/exports/a.py,
      r"\\myhost\exports" gets prepended to sys.path. But it doesn't work.
      This means that in a.py, "import b" will fail even though b.py is
      present in the same directory.

      The workaround is to manually prepend a backslass to the UNC path in
      sys.path.

      Note the related defect: http://bugs.python.org/issue954115
      This intdoruces two functions for testing UNC paths, but it appears
      that these functions are nowhere used!

    2. kristjanvalur
      added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      type-bugAn unexpected behavior, bug, or error
      on Aug 25, 2008

    3. kristjanvalur commented on Aug 25, 2008

      @kristjanvalur
      kristjanvalurmannequin
      on Aug 25, 2008
      MannequinAuthor

      Correction: The workaround is to _append_ a backslash.

    4. loewis commented on Oct 7, 2008

      @loewis
      loewismannequin
      on Oct 7, 2008
      Mannequin

      Kristjan, you suggested this issue for consideration for 2.5.3.

      Is there an actual patch to apply?

      If not, the issue should get forwarded to 2.7 (and then to 2.8, and so
      on, until somebody actually comes up with a patch).

    5. kristjanvalur commented on Oct 7, 2008

      @kristjanvalur
      kristjanvalurmannequin
      on Oct 7, 2008
      MannequinAuthor

      No, not really.
      Again, I refer to defect 954115 by glchapman. And note that those
      functions added there are actually not used.
      I was hoping that there was someone here more familiar with importing
      on PC.
      I'll go and see if the old defect still applies and if there is perhaps
      a more general fix to be made.

    6. loewis commented on Oct 7, 2008

      @loewis
      loewismannequin
      on Oct 7, 2008
      Mannequin

      Ok, un-targetting this from 2.5.3 then.

      Usage of IsUNCRoot disappeared as part of r42230, which dropped usage of
      the C library for stat implementations. This only affects os.stat,
      though, so I don't see the relation to this issue.

      For the record: What *exactly* is the problem? I.e. specifically, what
      do you do, what happens, what do you expect to happen instead?

    7. ocean-city commented on Oct 7, 2008

      @ocean-city
      ocean-citymannequin
      on Oct 7, 2008
      Mannequin

      I think this is stat(2) problem on windows. Please try following test
      program.

      #include <stdio.h>
#include <sys/stat.h>
#include <windows.h>

void test(const char *path)
{
    struct stat st;

    printf("%s %d %d\n", path, stat(path, &st), GetFileAttributes(path));
}

int main()
{
    test("e:\\shared");
    test("e:\\shared\\"); /* issue1293 */
    test("e:\\shared\\a.py");
    test("\\\\whiterab-c2znlh\\shared"); /* this issue */
    test("\\\\whiterab-c2znlh\\shared\\");
    test("\\\\whiterab-c2znlh\\shared\\a.py");
}

      And this is result.

      e:\shared 0 16
      e:\shared\ -1 16
      e:\shared\a.py 0 32
      \\whiterab-c2znlh\shared -1 16
      \\whiterab-c2znlh\shared\ 0 16
      \\whiterab-c2znlh\shared\a.py 0 32

      As discussed in bpo-1293, stat(2) fails for the normal folder path with
      trailing slash, and also fails for the UNC folder path without trailing
      slash. I'm using VC6, but same behavior on VC9?

      trunk/Python/import.c(3160) and trunk/Modules/zipimport.c(99) is using
      stat(2).

      I'll create patch to prove my observation. :-)

    8. ocean-city commented on Oct 7, 2008

      @ocean-city
      ocean-citymannequin
      on Oct 7, 2008
      Mannequin

      Ah, of cource, please change path to fit you environment. > test prog

    9. ocean-city commented on Oct 8, 2008

      @ocean-city
      ocean-citymannequin
      on Oct 8, 2008
      Mannequin

      zipimport.c seems fine, because stat(2) succeeds for UNC file. It fails
      for UNC folder. (zip file is absolutely file)

      Already fix for bpo-1293 was in, so maybe I should create the patch for
      that direction but... anyway this issue seems to be fixed by my patch. I
      also confirmed the test script in http://bugs.python.org/msg56523 works.

    10. ocean-city commented on Oct 8, 2008

      @ocean-city
      ocean-citymannequin
      on Oct 8, 2008
      Mannequin

      Just humble thought...
      If we can replace stat(2) + S_ISDIR/S_ISREG check with
      GetFileAttributesEx, maybe we are safe for this kind of problem, and can
      solve bpo-3099 same time? :-)

    11. ocean-city
      added
      OS-windows
      on Oct 10, 2008

    12. kristjanvalur commented on Jan 5, 2009

      @kristjanvalur
      kristjanvalurmannequin
      on Jan 5, 2009
      MannequinAuthor

      Okay, I've tested the patch and made some beauty fixes.
      Can we have this in, please?

    13. kristjanvalur commented on Jan 9, 2009

      @kristjanvalur
      kristjanvalurmannequin
      on Jan 9, 2009
      MannequinAuthor

      Checked in as revision: 68457

    14. kristjanvalur
      closed this as completedon Jan 9, 2009

    15. benjaminp commented on Jan 23, 2009

      @benjaminp
      benjaminp
      on Jan 23, 2009
      Contributor

      This fix needs to be ported to the py3k branch. Can somebody please do it?

    16. ocean-city commented on Jan 23, 2009

      @ocean-city
      ocean-citymannequin
      on Jan 23, 2009
      Mannequin

      Merged in r68873(py3k).

    17. ggenellina commented on Jan 24, 2009

      @ggenellina
      ggenellinamannequin
      on Jan 24, 2009
      Mannequin

      The path variable should be PyMem_Free'd (in both trunk and py3k)
      (also, I don't see any specific test - is there any?)

    18. kristjanvalur commented on Jan 24, 2009

      @kristjanvalur
      kristjanvalurmannequin
      on Jan 24, 2009
      MannequinAuthor

      added the mem release in r68882.
      I'll try to add test cases too.

    19. kristjanvalur commented on Jan 24, 2009

      @kristjanvalur
      kristjanvalurmannequin
      on Jan 24, 2009
      MannequinAuthor

      Added tests for UNC path imports in r68883 and r68884

    20. ocean-city commented on Jan 24, 2009

      @ocean-city
      ocean-citymannequin
      on Jan 24, 2009
      Mannequin

      The path variable should be PyMem_Free'd

      Sorry if I'm missing something, but is this really needed?
      Other PyArg_ParseTuple(args, "s... doesn't seem to have
      corresponding PyMem_Free.

      static PyObject *
imp_new_module(PyObject *self, PyObject *args)
{
	char *name;
	if (!PyArg_ParseTuple(args, "s:new_module", &name))
		return NULL;
	return PyModule_New(name);
}

    21. loewis commented on Jan 24, 2009

      @loewis
      loewismannequin
      on Jan 24, 2009
      Mannequin

      Sorry if I'm missing something, but is this really needed?

      Yes, the "es" converter allocates memory.

    22. ocean-city commented on Jan 24, 2009

      @ocean-city
      ocean-citymannequin
      on Jan 24, 2009
      Mannequin

      Ah, "es" is used in py3k, thanks. And sorry about my merge which had
      memory leak.

    23. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      OS-windowsinterpreter-core(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions