unable to describe root directory on thumb drive

Bug #613153 reported by Rob Keeney on 2010-08-03
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
leo-editor
Medium
Edward K. Ream

Bug Description

Environment:
-Running WinXP
-Launching Leo with C:\ as the root directory
-Opening Leo file stored on portable thumb drive (drive letters may be different depending on which machine it's connected to)

Leo file is here:
E:\Documents\Leo Outlines\ (drive letter E:\ is variable)

Wanting to create @thin node to save file to here:
E:\Documents\Web Site\

Tried:
@thin E:\Documents\Web Site\
This works but only on machines that assign E: to the thumb drive)

@thin \Documents\Web Site\index.html
This produces the following error:
errors writing: C:\Documents\Web Site\index.html
path does not exist: C:\Documents\Web Site

@thin .\Documents\Web Site\index.html
This produces the following error:
errors writing: E:\Documents\Leo Outlines\Documents\Web Site\index.html
path does not exist: E:\Documents\Leo Outlines\Documents\Web Site

@thin ..\Documents\Web Site\index.html
This produces the following error:
errors writing: E:\Documents\Documents\Web Site\index.html
path does not exist: E:\Documents\Documents\Web Site

I've tried up to three dots (same result as above).

I need to know how to specify a correct path when the root directory drive letter is variable.

Ville M. Vainio (villemvainio) wrote :

I think this is a legitimate bug.

Path descriptions in a leo document should be relative to the .leo file. If the .leo file is in E: drive, \ should refer to the root of the E drive.

On Tue, 03 Aug 2010 20:16:22 -0000
Rob Keeney <email address hidden> wrote:

> Leo file is here:
> E:\Documents\Leo Outlines\ (drive letter E:\ is variable)
>
> Wanting to create @thin node to save file to here:
> E:\Documents\Web Site\

> @thin ..\Documents\Web Site\index.html

Try @thin ..\Web Site\index.html

(or ..\..\Documents\Web Site\index.html, but they're equivalent)

.. to step up out of Leo Outlines, and the Web Site to step into the dir.

Also, if that fails, try

@thin ../Web Site/index.html just to see what happens.

Cheers -Terry

Thanks for clarifying that. I suppose I wasn't sure what to expect. I filed
the bug but wasn't sure if it's not more of a feature request than a bug. If
I can figure this out, it will really help in my utilization of Leo for
portability.

Regards,
Rob............

On Tue, Aug 3, 2010 at 4:35 PM, Ville M. Vainio <email address hidden> wrote:

> I think this is a legitimate bug.
>
> Path descriptions in a leo document should be relative to the .leo file.
> If the .leo file is in E: drive, \ should refer to the root of the E
> drive.
>
> --
> unable to describe root directory on thumb drive
> https://bugs.launchpad.net/bugs/613153
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Leo: a programmer's editor and more: New
>
> Bug description:
> Environment:
> -Running WinXP
> -Launching Leo with C:\ as the root directory
> -Opening Leo file stored on portable thumb drive (drive letters may be
> different depending on which machine it's connected to)
>
> Leo file is here:
> E:\Documents\Leo Outlines\ (drive letter E:\ is variable)
>
> Wanting to create @thin node to save file to here:
> E:\Documents\Web Site\
>
> Tried:
> @thin E:\Documents\Web Site\
> This works but only on machines that assign E: to the thumb drive)
>
> @thin \Documents\Web Site\index.html
> This produces the following error:
> errors writing: C:\Documents\Web Site\index.html
> path does not exist: C:\Documents\Web Site
>
> @thin .\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Leo Outlines\Documents\Web Site\index.html
> path does not exist: E:\Documents\Leo Outlines\Documents\Web Site
>
> @thin ..\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Documents\Web Site\index.html
> path does not exist: E:\Documents\Documents\Web Site
>
> I've tried up to three dots (same result as above).
>
> I need to know how to specify a correct path when the root directory drive
> letter is variable.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/leo-editor/+bug/613153/+subscribe
>

Try @thin ..\Web Site\index.html
>

Does not work

>
> (or ..\..\Documents\Web Site\index.html, but they're equivalent)
>

This *does* work (apparently not equivalent).

>
> .. to step up out of Leo Outlines, and the Web Site to step into the
> dir.
>
> Also, if that fails, try
>
> @thin ../Web Site/index.html just to see what happens.
>

Leo definitely does not like this one!

On Tue, 03 Aug 2010 21:05:48 -0000
Rob Keeney <email address hidden> wrote:

> > Try @thin ..\Web Site\index.html
>
> Does not work
>
> >
> > (or ..\..\Documents\Web Site\index.html, but they're equivalent)
> >
>
> This *does* work (apparently not equivalent).

Hmm. That's weird. I thought your original bug was invalid because, with .., you were going up one from Leo Outlines, i.e. you were standing in the Documents directory, then you attempted to go down into a Documents directory, which did not exist at that level.

So @thin ..\Web Site\index.html should have been what you wanted and @thin ..\..\Documents\Web Site\index.html an ungainly alternative.

I'm unable to confirm, using the latest Leo snapshot (http://www.greygreen.org/leo/) both ..\Web Site\index.html and ..\..\Documents\Web Site\index.html work, provided all needed destination directories exists. WinXP.

You didn't identify the version of Leo you use, I know there was a change to this path handling not that long ago.

Cheers -Terry

Terry, did you test on a different drive than where Leo was installed?

On Wed, Aug 4, 2010 at 12:30 AM, tbnorth <email address hidden> wrote:
> On Tue, 03 Aug 2010 21:05:48 -0000
> Rob Keeney <email address hidden> wrote:
>
>> > Try @thin ..\Web Site\index.html
>>
>> Does not work
>>
>> >
>> > (or ..\..\Documents\Web Site\index.html, but they're equivalent)
>> >
>>
>> This *does* work (apparently not equivalent).
>
> Hmm.  That's weird.  I thought your original bug was invalid because,
> with .., you were going up one from Leo Outlines, i.e. you were standing
> in the Documents directory, then you attempted to go down into a
> Documents directory, which did not exist at that level.
>
> So @thin ..\Web Site\index.html should have been what you wanted and
> @thin ..\..\Documents\Web Site\index.html an ungainly alternative.
>
> I'm unable to confirm, using the latest Leo snapshot
> (http://www.greygreen.org/leo/) both ..\Web Site\index.html and
> ..\..\Documents\Web Site\index.html work, provided all needed
> destination directories exists.  WinXP.
>
> You didn't identify the version of Leo you use, I know there was a
> change to this path handling not that long ago.
>
> Cheers -Terry
>
> --
> unable to describe root directory on thumb drive
> https://bugs.launchpad.net/bugs/613153
> You received this bug notification because you are a member of The Leo
> editor team, which is subscribed to leo-editor.
>
> Status in Leo: a programmer's editor and more: New
>
> Bug description:
> Environment:
> -Running WinXP
> -Launching Leo with C:\ as the root directory
> -Opening Leo file stored on portable thumb drive (drive letters may be different depending on which machine it's connected to)
>
> Leo file is here:
> E:\Documents\Leo Outlines\ (drive letter E:\ is variable)
>
> Wanting to create @thin node to save file to here:
> E:\Documents\Web Site\
>
> Tried:
> @thin E:\Documents\Web Site\
> This works but only on machines that assign E: to the thumb drive)
>
> @thin \Documents\Web Site\index.html
> This produces the following error:
> errors writing: C:\Documents\Web Site\index.html
> path does not exist: C:\Documents\Web Site
>
> @thin .\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Leo Outlines\Documents\Web Site\index.html
> path does not exist: E:\Documents\Leo Outlines\Documents\Web Site
>
> @thin ..\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Documents\Web Site\index.html
> path does not exist: E:\Documents\Documents\Web Site
>
> I've tried up to three dots (same result as above).
>
> I need to know how to specify a correct path when the root directory drive letter is variable.
>
>
>

--
Ville M. Vainio @@ Forum Nokia

Rob Keeney (largo84) wrote :

Terry, after further review I see that I characterized the error
incorrectly. You're right that ..\Web Site\ works the same as
..\..\Documents\Web Site\

However, \Documents\Web Site\ still does *not* work as expected. Not sure if
this bug should be closed or not as I have a workable solution (..\..\etc.
will reference back through the drive root).

BTW, I'm using Leo v4.7.1 final

Rob..................

It should not be closed because it's still broken :)
--
Sent from my Nokia N900

----- Original message -----
> Terry, after further review I see that I characterized the error
> incorrectly. You're right that ..\Web Site\ works the same as
> ..\..\Documents\Web Site\
>
> However, \Documents\Web Site\ still does *not* work as expected. Not
> sure if this bug should be closed or not as I have a workable solution
> (..\..\etc. will reference back through the drive root).
>
> BTW, I'm using Leo v4.7.1 final
>
> Rob..................
>
> --
> unable to describe root directory on thumb drive
> https://bugs.launchpad.net/bugs/613153
> You received this bug notification because you are a member of The Leo
> editor team, which is subscribed to leo-editor.
>
> Status in Leo: a programmer's editor and more: New
>
> Bug description:
> Environment:
> -Running WinXP
> -Launching Leo with C:\ as the root directory
> -Opening Leo file stored on portable thumb drive (drive letters may be
> different depending on which machine it's connected to)
>
> Leo file is here:
> E:\Documents\Leo Outlines\ (drive letter E:\ is variable)
>
> Wanting to create @thin node to save file to here:
> E:\Documents\Web Site\
>
> Tried:
> @thin E:\Documents\Web Site\
> This works but only on machines that assign E: to the thumb drive)
>
> @thin \Documents\Web Site\index.html
> This produces the following error:
> errors writing: C:\Documents\Web Site\index.html
> path does not exist: C:\Documents\Web Site
>
> @thin .\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Leo Outlines\Documents\Web Site\index.html
> path does not exist: E:\Documents\Leo Outlines\Documents\Web Site
>
> @thin ..\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Documents\Web Site\index.html
> path does not exist: E:\Documents\Documents\Web Site
>
> I've tried up to three dots (same result as above).
>
> I need to know how to specify a correct path when the root directory
> drive letter is variable.
>
>

On Wed, 04 Aug 2010 13:39:28 -0000
"Ville M. Vainio" <email address hidden> wrote:

> Terry, did you test on a different drive than where Leo was installed?

Yes, I had the .leo file and .html files on F: just as Rob described (except he used E: and it was a removable rather than internal drive, but let's assume it's not sensitive to media type or drive letter value :-) Leo was "installed" on the desktop, the C: drive.

> It should not be closed because it's still broken :)

Which aren't working as you'd expect? The paths in the original report were all wrong, the correct relative paths and absolute path (E:\Documents\Web Site\) work, and I'm not sure if '@thin \Documents\Web Site\index.html' really means anything in Windows.

> Sent from my Nokia N900
>
> ----- Original message -----
> > Terry, after further review I see that I characterized the error
> > incorrectly. You're right that ..\Web Site\ works the same as
> > ..\..\Documents\Web Site\
> >
> > However, \Documents\Web Site\ still does *not* work as expected. Not
> > sure if this bug should be closed or not as I have a workable solution
> > (..\..\etc. will reference back through the drive root).
> >
> > BTW, I'm using Leo v4.7.1 final
> >
> > Rob..................
> >
> > --
> > unable to describe root directory on thumb drive
> > https://bugs.launchpad.net/bugs/613153
> > You received this bug notification because you are a member of The Leo
> > editor team, which is subscribed to leo-editor.
> >
> > Status in Leo: a programmer's editor and more: New
> >
> > Bug description:
> > Environment:
> > -Running WinXP
> > -Launching Leo with C:\ as the root directory
> > -Opening Leo file stored on portable thumb drive (drive letters may be
> > different depending on which machine it's connected to)
> >
> > Leo file is here:
> > E:\Documents\Leo Outlines\ (drive letter E:\ is variable)
> >
> > Wanting to create @thin node to save file to here:
> > E:\Documents\Web Site\
> >
> > Tried:
> > @thin E:\Documents\Web Site\
> > This works but only on machines that assign E: to the thumb drive)
> >
> > @thin \Documents\Web Site\index.html
> > This produces the following error:
> > errors writing: C:\Documents\Web Site\index.html
> > path does not exist: C:\Documents\Web Site
> >
> > @thin .\Documents\Web Site\index.html
> > This produces the following error:
> > errors writing: E:\Documents\Leo Outlines\Documents\Web Site\index.html
> > path does not exist: E:\Documents\Leo Outlines\Documents\Web Site
> >
> > @thin ..\Documents\Web Site\index.html
> > This produces the following error:
> > errors writing: E:\Documents\Documents\Web Site\index.html
> > path does not exist: E:\Documents\Documents\Web Site
> >
> > I've tried up to three dots (same result as above).
> >
> > I need to know how to specify a correct path when the root directory
> > drive letter is variable.
> >
> >
>

On Wed, Aug 4, 2010 at 7:25 PM, tbnorth <email address hidden> wrote:

> Which aren't working as you'd expect?  The paths in the original report
> were all wrong, the correct relative paths and absolute path
> (E:\Documents\Web Site\) work, and I'm not sure if '@thin \Documents\Web
> Site\index.html' really means anything in Windows.

\ means "root directory of current drive" in windows. Therefore, it
should mean the root directory of the drive where .leo file is
located.

--
Ville M. Vainio @@ Forum Nokia

Rob Keeney (largo84) wrote :

After more extensive testing (see attached Leo file for details) I have concluded the following:

* The relative path \Documents\etc. does indeed work *sometimes*
* It works after the file has already been opened and directed to the absolute named path (E:\Documents\etc.)
* It also works if the file is re-opened after closing as long as Leo has remained open.
* It does *not* work when opening the file for the first time. In these cases, Leo attempts to read the @file from C:\Documents\etc. (which, of course, don't exist).

What this essentially means is that the relative path write mechanism works but not the read mechanism since it needs for the file to already be opened and used for Leo to know where the current drive path is (at least that's how I interpret the results).

Thoughts?
Rob.................

On Thu, 05 Aug 2010 14:22:57 -0000
Rob Keeney <email address hidden> wrote:

> * The relative path \Documents\etc. does indeed work *sometimes*

Just to be clear, the ..\Web\etc. or ..\..\Documents\Web\etc. form always works? It's just the \Documents\etc. for which doesn't? I'd think of the .. forms as relative paths, and the \Documents\etc. form as a Windows variant, an 'absolute path for the current drive', for which there's no equivalent concept in unix.

My guess is that the sort of absoluteness is confusing the code, which is assuming it doesn't need to work out the starting point (defined by the location of the .leo file) if the path is absolute. So it then becomes a matter of the python process current directory, which is pretty much random, and influenced by some of the things you manipulated.

It should be easy enough to make the \Documents\etc. for work, I'll have a look at the code.

Cheers -Terry

tbnorth (terry-n-brown) wrote :

On Thu, 05 Aug 2010 15:46:41 -0000
tbnorth <email address hidden> wrote:

> It should be easy enough to make the \Documents\etc. for work, I'll have
> a look at the code.

Ha ha. So, here's the open Python bug which is fouling things up:

http://bugs.python.org/issue1669539

Probably just a matter of sticking the drive letter of the .leo file into the calculated path if there's no drive letter there already. Will look more later.

Cheers -Terry

Rob Keeney (largo84) wrote :

Not sure as I didn't test these variants last night. I will now and report
back.

On Thu, Aug 5, 2010 at 11:46 AM, tbnorth <email address hidden> wrote:

> On Thu, 05 Aug 2010 14:22:57 -0000
> Rob Keeney <email address hidden> wrote:
>
> > * The relative path \Documents\etc. does indeed work *sometimes*
>
> Just to be clear, the ..\Web\etc. or ..\..\Documents\Web\etc. form
> always works? It's just the \Documents\etc. for which doesn't? I'd
> think of the .. forms as relative paths, and the \Documents\etc. form as
> a Windows variant, an 'absolute path for the current drive', for which
> there's no equivalent concept in unix.
>
> My guess is that the sort of absoluteness is confusing the code, which
> is assuming it doesn't need to work out the starting point (defined by
> the location of the .leo file) if the path is absolute. So it then
> becomes a matter of the python process current directory, which is
> pretty much random, and influenced by some of the things you
> manipulated.
>
> It should be easy enough to make the \Documents\etc. for work, I'll have
> a look at the code.
>
> Cheers -Terry
>
> --
> unable to describe root directory on thumb drive
> https://bugs.launchpad.net/bugs/613153
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Leo: a programmer's editor and more: New
>
> Bug description:
> Environment:
> -Running WinXP
> -Launching Leo with C:\ as the root directory
> -Opening Leo file stored on portable thumb drive (drive letters may be
> different depending on which machine it's connected to)
>
> Leo file is here:
> E:\Documents\Leo Outlines\ (drive letter E:\ is variable)
>
> Wanting to create @thin node to save file to here:
> E:\Documents\Web Site\
>
> Tried:
> @thin E:\Documents\Web Site\
> This works but only on machines that assign E: to the thumb drive)
>
> @thin \Documents\Web Site\index.html
> This produces the following error:
> errors writing: C:\Documents\Web Site\index.html
> path does not exist: C:\Documents\Web Site
>
> @thin .\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Leo Outlines\Documents\Web Site\index.html
> path does not exist: E:\Documents\Leo Outlines\Documents\Web Site
>
> @thin ..\Documents\Web Site\index.html
> This produces the following error:
> errors writing: E:\Documents\Documents\Web Site\index.html
> path does not exist: E:\Documents\Documents\Web Site
>
> I've tried up to three dots (same result as above).
>
> I need to know how to specify a correct path when the root directory drive
> letter is variable.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/leo-editor/+bug/613153/+subscribe
>

Rob Keeney (largo84) wrote :

After additional testing I found the following:

* ..\Documents\etc. does *not* work to write the file to correct location (path does not exist: E:\Documents\Documents\Web Site)
* ..\..\Documents\etc. *does* work for opening file for the first time. However, the number of ..\ repetitions needs to match the level of the .leo file. I suppose this is the reason I had trouble with one file as the .leo file was 3 directory levels removed from the root, therefore needed ..\..\..\Documents\etc. to work properly.

This means that I have a workable temporary solution as long as I match the ..\ repetitions to the location of the .leo file (at least that's not subject to change).

I saw your note about the open python bug, very interesting. Any idea if this is still an issue with python3k?

Rob...............

tbnorth (terry-n-brown) wrote :

On Thu, 05 Aug 2010 18:32:56 -0000
Rob Keeney <email address hidden> wrote:

> After additional testing I found the following:
>
> * ..\Documents\etc. does *not* work to write the file to correct location (path does not exist: E:\Documents\Documents\Web Site)
> * ..\..\Documents\etc. *does* work for opening file for the first time. However, the number of ..\ repetitions needs to match the level of the .leo file. I suppose this is the reason I had trouble with one file as the .leo file was 3 directory levels removed from the root, therefore needed ..\..\..\Documents\etc. to work properly.

Yep, that's all as it should be, the .. forms have been working correctly all along.

> This means that I have a workable temporary solution as long as I match
> the ..\ repetitions to the location of the .leo file (at least that's
> not subject to change).

Yep.

> I saw your note about the open python bug, very interesting. Any idea if
> this is still an issue with python3k?

It's listed as affecting all current versions and being still open, so yes. Basically they're stuck because the concept of 'absolute path' wasn't clearly thought through for Windows in the first place, and now they can't change the behavior of the function without breaking a lot of existing code.

tbnorth (terry-n-brown) wrote :
Download full text (4.7 KiB)

Edward, not sure if you're following this thread, but the fix turned out to be entangled with a lot of @<file> stuff, so I don't want to push it without your inspection.

Repeating the basic problem: for an @<file> node there is some parent path in effect at the point where you reach the node, based on the location of the .leo file and any relevant @path directives. For determination of the full path to the target file, the @<file> node can either extend the parent path with a relative path (simplest case, just the filename), or discard the parent path with an absolute path of its own. The problem arises when the @<file> introduces a Windows drive specific \absolute\path without specifying the drive. In that case the drive should come from the original parent path.

I think the diff below does that ok. It might do it in more places than was needed to fix the original problem, but I don't think it does it in any places where it shouldn't.

Also, I think the same issue would affect the scanning of @path directives, this diff doesn't address that, although the fix_windows_absolute() method it introduces could probably be used for that application also. Here's the diff:

=== modified file 'leo/core/leoAtFile.py'
--- leo/core/leoAtFile.py 2010-08-03 22:26:10 +0000
+++ leo/core/leoAtFile.py 2010-08-05 22:24:42 +0000
@@ -688,6 +688,8 @@
         else:
             fileName = None

+ fileName = g.fix_windows_absolute(self.c, root, fileName)
+
         return fileName
     #@+node:ekr.20100224050618.11547: *5* at.isFileLike
     def isFileLike (self,s):
@@ -2815,7 +2817,10 @@
                 at.targetFileName = root.atFileNodeName()
         else:
             at.targetFileName = root.atFileNodeName()
+
+ at.targetFileName = g.fix_windows_absolute(at.c, root, at.targetFileName)
         #@-<< set at.targetFileName >>
+
         at.initWriteIvars(root,at.targetFileName,
             nosentinels = nosentinels, thinFile = thinFile,
             scriptWrite = scriptWrite, toString = toString)
@@ -5166,7 +5171,9 @@
         else:
             fn = p.anyAtFileNodeName()
         if fn:
+ fn = g.fix_windows_absolute(c, p, fn)
             path = g.os_path_finalize_join(path,fn)
+
         else:
             g.trace('can not happen: not an @<file> node:',g.callers(4))
             for p2 in p.self_and_parents():

=== modified file 'leo/core/leoCommands.py'
--- leo/core/leoCommands.py 2010-08-01 17:16:51 +0000
+++ leo/core/leoCommands.py 2010-08-05 22:59:13 +0000
@@ -559,6 +559,7 @@
             if name: break

         if name:
+ name = g.fix_windows_absolute(self, p, name)
             name = g.os_path_finalize_join(path,name)
         return name
     #@+node:ekr.20091211111443.6265: *3* c.doBatchOperations & helpers

=== modified file 'leo/core/leoGlobals.py'
--- leo/core/leoGlobals.py 2010-07-31 12:00:58 +0000
+++ leo/core/leoGlobals.py 2010-08-05 22:52:47 +0000
@@ -936,6 +936,9 @@
     if name:
         theDir = g.os_path_dirname(name)
         if theDir and g.os_path_isabs(theDir):
+
+ theDir = g.fix_windows_absolute(c,p,theDir)
+
             if g.os_path_exists(theDir):
                 default_di...

Read more...

Ville M. Vainio (villemvainio) wrote :
Download full text (6.7 KiB)

For performance reasons the first thing you check before doing
anything else should be:

 if path[0] != "\\": return path

On Fri, Aug 6, 2010 at 2:01 AM, tbnorth <email address hidden> wrote:
> Edward, not sure if you're following this thread, but the fix turned out
> to be entangled with a lot of @<file> stuff, so I don't want to push it
> without your inspection.
>
> Repeating the basic problem: for an @<file> node there is some parent
> path in effect at the point where you reach the node, based on the
> location of the .leo file and any relevant @path directives.  For
> determination of the full path to the target file, the @<file> node can
> either extend the parent path with a relative path (simplest case, just
> the filename), or discard the parent path with an absolute path of its
> own.  The problem arises when the @<file> introduces a Windows drive
> specific \absolute\path without specifying the drive.  In that case the
> drive should come from the original parent path.
>
> I think the diff below does that ok.  It might do it in more places than
> was needed to fix the original problem, but I don't think it does it in
> any places where it shouldn't.
>
> Also, I think the same issue would affect the scanning of @path
> directives, this diff doesn't address that, although the
> fix_windows_absolute() method it introduces could probably be used for
> that application also.  Here's the diff:
>
> === modified file 'leo/core/leoAtFile.py'
> --- leo/core/leoAtFile.py       2010-08-03 22:26:10 +0000
> +++ leo/core/leoAtFile.py       2010-08-05 22:24:42 +0000
> @@ -688,6 +688,8 @@
>         else:
>             fileName = None
>
> +        fileName = g.fix_windows_absolute(self.c, root, fileName)
> +
>         return fileName
>     #@+node:ekr.20100224050618.11547: *5* at.isFileLike
>     def isFileLike (self,s):
> @@ -2815,7 +2817,10 @@
>                 at.targetFileName = root.atFileNodeName()
>         else:
>             at.targetFileName = root.atFileNodeName()
> +
> +        at.targetFileName = g.fix_windows_absolute(at.c, root, at.targetFileName)
>         #@-<< set at.targetFileName >>
> +
>         at.initWriteIvars(root,at.targetFileName,
>             nosentinels = nosentinels, thinFile = thinFile,
>             scriptWrite = scriptWrite, toString = toString)
> @@ -5166,7 +5171,9 @@
>         else:
>             fn = p.anyAtFileNodeName()
>         if fn:
> +            fn = g.fix_windows_absolute(c, p, fn)
>             path = g.os_path_finalize_join(path,fn)
> +
>         else:
>             g.trace('can not happen: not an @<file> node:',g.callers(4))
>             for p2 in p.self_and_parents():
>
> === modified file 'leo/core/leoCommands.py'
> --- leo/core/leoCommands.py     2010-08-01 17:16:51 +0000
> +++ leo/core/leoCommands.py     2010-08-05 22:59:13 +0000
> @@ -559,6 +559,7 @@
>             if name: break
>
>         if name:
> +            name = g.fix_windows_absolute(self, p, name)
>             name = g.os_path_finalize_join(path,name)
>         return name
>     #@+node:ekr.20091211111443.6265: *3* c.doBatchOperations & helpers
>
> === modified file 'leo/core/leoGlobals.py'
> --- leo/core/leoGlobals.py      201...

Read more...

Edward K. Ream (edreamleo) wrote :

On Thu, Aug 5, 2010 at 6:01 PM, tbnorth <email address hidden> wrote:
> Edward, not sure if you're following this thread,

I have, but not closely.

> but the fix turned out
> to be entangled with a lot of @<file> stuff, so I don't want to push it
> without your inspection.

Thanks. Please don't commit *any* change to Leo's @path logic without
consulting me first.

> Repeating the basic problem: for an @<file> node there is some parent
> path in effect at the point where you reach the node, based on the
> location of the .leo file and any relevant @path directives.  For
> determination of the full path to the target file, the @<file> node can
> either extend the parent path with a relative path (simplest case, just
> the filename), or discard the parent path with an absolute path of its
> own.  The problem arises when the @<file> introduces a Windows drive
> specific \absolute\path without specifying the drive.  In that case the
> drive should come from the original parent path.

Yuck. @path handling is extremely complex, and can't be made all that simple.

> I think the diff below does that ok.  It might do it in more places than
> was needed to fix the original problem, but I don't think it does it in
> any places where it shouldn't.

I don't like this solution. The only clean place to handle this
difficult detail is in the g.os_path_xxx methods, including
g.os_path_finalize_join. These functions exist for two important
reasons:

1. To ensure that Leo handles unicode properly in file names and

2. To handle the kind of details we have here.

Please focus any fix on these functions. If it turns out that some
code doesn't call these methods, but should, then *that* is the place
to make fixes outside leoGlobals.py.

Perhaps I am misunderstanding your intention. It's fine with me if
g.fix_windows_absolute is a helper for the g.os_path functions, but I
do not want special-purpose hacks being added outside of leoGlobals.py
unless that is absolutely necessary.

Edward

tbnorth (terry-n-brown) wrote :

On Sat, 14 Aug 2010 11:39:19 -0000
"Edward K. Ream" <email address hidden> wrote:

> On Thu, Aug 5, 2010 at 6:01 PM, tbnorth <email address hidden> wrote:
> > Edward, not sure if you're following this thread,
>
> I have, but not closely.
>
> > but the fix turned out
> > to be entangled with a lot of @<file> stuff, so I don't want to push it
> > without your inspection.
>
> Thanks. Please don't commit *any* change to Leo's @path logic without
> consulting me first.
>
> > Repeating the basic problem: for an @<file> node there is some parent
> > path in effect at the point where you reach the node, based on the
> > location of the .leo file and any relevant @path directives.  For
> > determination of the full path to the target file, the @<file> node can
> > either extend the parent path with a relative path (simplest case, just
> > the filename), or discard the parent path with an absolute path of its
> > own.  The problem arises when the @<file> introduces a Windows drive
> > specific \absolute\path without specifying the drive.  In that case the
> > drive should come from the original parent path.
>
> Yuck. @path handling is extremely complex, and can't be made all that
> simple.
>
> > I think the diff below does that ok.  It might do it in more places than
> > was needed to fix the original problem, but I don't think it does it in
> > any places where it shouldn't.
>
> I don't like this solution. The only clean place to handle this
> difficult detail is in the g.os_path_xxx methods, including
> g.os_path_finalize_join. These functions exist for two important
> reasons:

I think the problem with fixing it there is that the paths in questions (paths starting with a single backslash on Windows) can't be resolved without knowing what the "current drive" is, and that can only be known by knowing the directory in effect (as a result of any @paths) at the @<file> node in question.

More clearly :-} - Leo switches program flow on the basis of os.path.isabs(), but os.path.isabs() gives a bogus result for paths starting with a single backslash on Windows. Aha! :-) Maybe that's how the fix can be pushed into g.os_path_xxx, we just need a g.os_path_isabs which knows such paths are really relative, and to make sure the other g.os_path_xxx handle the joins correctly. I was thinking it couldn't be handled in g.os_path_xxx because you lose the leo-current-directory context by the time you're there, but that's only when os.path.isabs() is giving a wrong answer.

I'll re-visit the changes needed taking that approach.

Cheers -Terry

> 1. To ensure that Leo handles unicode properly in file names and
>
> 2. To handle the kind of details we have here.
>
> Please focus any fix on these functions. If it turns out that some
> code doesn't call these methods, but should, then *that* is the place
> to make fixes outside leoGlobals.py.
>
> Perhaps I am misunderstanding your intention. It's fine with me if
> g.fix_windows_absolute is a helper for the g.os_path functions, but I
> do not want special-purpose hacks being added outside of leoGlobals.py
> unless that is absolutely necessary.
>
> Edward
>

Edward K. Ream (edreamleo) wrote :

On Sat, Aug 14, 2010 at 9:18 AM, tbnorth <email address hidden> wrote:

> Aha! :-)  Maybe that's how
> the fix can be pushed into g.os_path_xxx, we just need a g.os_path_isabs
> which knows such paths are really relative, and to make sure the other
> g.os_path_xxx handle the joins correctly.

Excellent. Efficiency is not an issue here: we are talking
microseconds at most for an "open". Solving this cleanly will save us
hours, if not days, of discussion, support, etc ;-)

EKR

tbnorth (terry-n-brown) wrote :

On Sat, 14 Aug 2010 14:18:46 -0000
tbnorth <email address hidden> wrote:

> Aha! :-) Maybe that's how
> the fix can be pushed into g.os_path_xxx, we just need a g.os_path_isabs
> which knows such paths are really relative, and to make sure the other
> g.os_path_xxx handle the joins correctly.

Meh, g.os_path_join doesn't handle these correctly, it says:

>>> os.path.join("a:\\path", "\\other")
'\\other'

So, I've written code for that case. What about this one:

>>> os.path.join("\\\\server\\share", "\\root\\relative")
'\\root\\relative'

That's wrong, but what's right,
'\\\\server\\share\\root\\relative' or
'\\\\server\\root\\relative' ???

The first, I guess?

Cheers -Terry

tbnorth (terry-n-brown) wrote :

On Mon, 16 Aug 2010 16:32:34 -0500
Terry Brown <email address hidden> wrote:

> Meh, g.os_path_join doesn't handle these correctly, it says:
>
> >>> os.path.join("a:\\path", "\\other")
> '\\other'

Whoops, mixed g.os_path_join and os.path.join, but they both give the same wrong answer

Edward K. Ream (edreamleo) wrote :

On Mon, Aug 16, 2010 at 4:32 PM, tbnorth <email address hidden> wrote:

>>>> os.path.join("a:\\path", "\\other")

os.path.sep determines the action of os.path.join:

1. On windows, r'\other' is an absolute path, so it *must* override
whatever precedes it. Any other action is **wrong**. Thus, the one
and only correct value of:

    os.path.join(r'a:\path',r'\other')

is r'\other'.

2. On linux, '/other' is an absolute path, so it must override
whatever precedes it. Any other action is **wrong**. Thus, the one
and only correct value of:

    g.os.path.join(ANYTHING,'/other')

is '/other'.

Imo, the problem is that on Windows os.path.normpath converts forward
slashes to backslashes, but on Linux the reverse does *not* happen:
backslashes are *not* converted to forward slashes. Thus, on Linux,

    os.path.join(r'\a:\x',r'\y')

yields a:\x/\y (!)

I propose that g.os_path_normpath do a "two-way" convert: that is,
convert *both* slashes and backslashes to os.path.sep.

Any comments?

Edward

tbnorth (terry-n-brown) wrote :

On Tue, 17 Aug 2010 16:13:51 -0000
"Edward K. Ream" <email address hidden> wrote:

> On Mon, Aug 16, 2010 at 4:32 PM, tbnorth <email address hidden>
> wrote:
>
> >>>> os.path.join("a:\\path", "\\other")
>
> os.path.sep determines the action of os.path.join:
>
> 1. On windows, r'\other' is an absolute path

It's not exactly absolute, it's relative to the root of the "current drive", a concept which doesn't exist in unix.

See http://bugs.python.org/issue1669539 - still open after 3 years and affecting all current versions.

> , so it *must* override
> whatever precedes it. Any other action is **wrong**. Thus, the one
> and only correct value of:
>
> os.path.join(r'a:\path',r'\other')
>
> is r'\other'.

But when you try and resolve this is depends on the current working directory of the python process, making is useless. I think the only useful way to resolve it is to return r'a:\other'. Otherwise you resolve to r'<random-drive-letter>:\other'.

In the context of the Windows shell, '\foo' being the root of the current drive makes sense. In the context of a leo tree, the 'current drive' should be defined by the path (starting with the location of the .leo file and as modified by @path directives) leading to the node, not the random state of the working directory of the python process.

> 2. On linux, '/other' is an absolute path, so it must override

There are no problem in the unix case, where drives don't exist :-)

[snip]

> Imo, the problem is that on Windows os.path.normpath converts forward
> slashes to backslashes, but on Linux the reverse does *not* happen:
> backslashes are *not* converted to forward slashes. Thus, on Linux,

I don't think this is relevant to the OP's problem, namely the a leo file on a usb drive (undefined drive letter) has no way of referencing directories starting from the root of the usb drive.

I have some code which minimally tweaks g.os_path_join behvior for this case. Also this case

g.os_path_join(r'\\server\share\some\path', r'\docs\etc'). The useful response, analogous to the above, would be r'\\server\share\docs\etc'.

I'll post the diff, although I'm not sure if we're on the same page with the problem yet :-)

Cheers -Terry

> os.path.join(r'\a:\x',r'\y')
>
> yields a:\x/\y (!)
>
> I propose that g.os_path_normpath do a "two-way" convert: that is,
> convert *both* slashes and backslashes to os.path.sep.
>
> Any comments?
>
> Edward
>

Changed in leo-editor:
assignee: nobody → Edward K. Ream (edreamleo)
importance: Undecided → Medium
status: New → Confirmed
tbnorth (terry-n-brown) wrote :

On Fri, 27 Aug 2010 16:30:07 -0000
"Edward K. Ream" <email address hidden> wrote:

> ** Changed in: leo-editor
> Importance: Undecided => Medium
>
> ** Changed in: leo-editor
> Status: New => Confirmed
>
> ** Changed in: leo-editor
> Assignee: (unassigned) => Edward K. Ream (edreamleo)

I will post some code for this ASAP, so if you could hit other Medium's first, you should have something to work with on this. Or you can reassign to me if you want, I won't push to the trunk without OK for these core behaviors.

Edward K. Ream (edreamleo) wrote :

On Sun, Aug 29, 2010 at 8:26 PM, tbnorth <email address hidden> wrote:

> I will post some code for this ASAP, so if you could hit other Medium's
> first, you should have something to work with on this.

Thanks for your help.

> Or you can
> reassign to me if you want, I won't push to the trunk without OK for
> these core behaviors.

Assigning the bug to you is fine, but it doesn't matter.

Feel free to push to the trunk, provided that all unit tests pass.
I'm quite sure you understand the issues better than I do. Besides,
the next release is a1 :-)

One test is failing at present, it's ok to let that continue to fail.
 Just don't allow any *new* failures. It would be good if you could
create one or more unit tests that a) fail at present and b) succeed
with your new code.

Edward

Edward K. Ream (edreamleo) wrote :

I'm going to demote this to a wishlist item, meaning *only* that *I* am not committed to fixing it. It is still ok if Terry fixes this, provided he gives notice of his intention.

The convention is this:

- Only high-priority bugs are certain to be fixed for Leo 4.8 final.

- I *might* attempt fixes for medium-priority fixes.

- Low-priority bugs will not be fixed for Leo 4.8 final.

Changed in leo-editor:
importance: Medium → Wishlist
tbnorth (terry-n-brown) wrote :

On Fri, 29 Oct 2010 11:24:54 -0000
"Edward K. Ream" <email address hidden> wrote:

> I'm going to demote this to a wishlist item, meaning *only* that *I* am
> not committed to fixing it. It is still ok if Terry fixes this,
> provided he gives notice of his intention.

As noted in the other bug I just responded to, I'm very busy currently and on vacation for a week a week from tomorrow, so it's definitely low to no priority for me.

Edward K. Ream (edreamleo) wrote :

On Fri, Oct 29, 2010 at 10:30 AM, tbnorth <email address hidden> wrote:
> On Fri, 29 Oct 2010 11:24:54 -0000
> "Edward K. Ream" <email address hidden> wrote:
>
>> I'm going to demote this to a wishlist item, meaning *only* that *I* am
>> not committed to fixing it.  It is still ok if Terry fixes this,
>> provided he gives notice of his intention.
>
> As noted in the other bug I just responded to, I'm very busy currently
> and on vacation for a week a week from tomorrow, so it's definitely low
> to no priority for me.

Alright then. We'll save this for after 4.8 final.

Edward

Edward K. Ream (edreamleo) wrote :

I am going to promote this to a high-priority bug so as to take advantage of the discussion at the thread

viewrendered - file not found
http://groups.google.com/group/leo-editor/browse_thread/thread/928b7222cebf1b7c

Changed in leo-editor:
importance: Wishlist → High
Edward K. Ream (edreamleo) wrote :

I am going to demote this to medium severity for now, meaning that it will not be part of Leo 4.10.

Changed in leo-editor:
importance: High → Medium
Edward K. Ream (edreamleo) wrote :

I'm marking this as "fix released" so it no longer appears in searches.
A link to this bug now appears here: https://github.com/leo-editor/leo-editor/issues

Changed in leo-editor:
status: Confirmed → Fix Released
Edward K. Ream (edreamleo) wrote :

Hurray! At last we have a real solution. Use the %~dp0 syntax. Example::

  %~dp0\Python27\python.exe %~dp0\Leo-editor\launchLeo.py

http://ss64.com/nt/syntax-args.html
http://stackoverflow.com/questions/5034076/what-does-dp0-mean-and-how-does-it-work

I have just created a FAQ entry for this, so at last this issue is closed.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.