Re: Symlinks already present

[Cameron Simpson]

On 31Aug2020 14:20, Chris Angelico  wrote:
>On Mon, Aug 31, 2020 at 1:17 PM Cameron Simpson  wrote:
>> Each "source" symlink has its own inode. But if you os.stat() the
>> symlink it follows the symlink and you get the inode for the "target"
>> directory - two symlinks which point at the same directory will return the 
>> same
>> inode and thus (st_dev,st_ino) in that stat result.
>>
>> That can be used for comparison, and you don't need to readlink or
>> anything like that - let the OS do it all for you during the os.stat()
>> call.
>
>Note that this is only the case if os.stat is called with
>follow_symlinks=True, which is the default, but isn't the only way to
>do things.

Maybe not, but it is the way I'm suggesting.

>> >[old-Unix-guy story: Way back when, SunOS used to allow you (if 
>> >root)
>> >to create a hard link to a directory.  It's not something you did a
>> >second time.]
>>
>> It's a well defined operation. There are some policy choices an OS can
>> make about some of the side effects (how does pwd work? how you got
>> there? or some underlying "real" path - this spills over into "what does
>> ".." mean?), etc. But having made those choices, the idea is just fine.
>
>Is it well defined?

It can be well defined. Probably should have phrased it that way.

>Because of the ".." issue, it's not going to be as
>symmetric as hardlinking files is. You can move a file by hardlinking
>it and then unlinking the original name. If you do that with a
>directory, at what point do you update its parent pointer? What
>happens if you create TWO more hardlinks, and then unlink the original
>name? Can you even *have* a single concept of a "real path" without it
>basically just being symlinks in disguise?

Shrug. Who says ".." is wired to the directory, and not the user's 
process context? Who says a wired to the directory ".." needs changing 
at any time except when its referring link count goes to 1? There are 
many choices here. Making those choices is a policy decision for the OS 
implementor, and they all have their costs and benefits.

>BTW, the pwd issue actually isn't an issue, since it really *will* be
>"how you got there". You can see that with modern systems if you have
>symlinks in the path, or rename a directory: [...snip...]

Yeah, makes me ill. That's because these days "pwd" is usually a shell 
builtin with funny semantics and a cache/sanity=check against $PWD 
(which gets computed as you cd around, typically). And if has a -P 
option and friends explicitly because of this hideous stuff.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Chris Angelico]

On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson  wrote:
> >Because of the ".." issue, it's not going to be as
> >symmetric as hardlinking files is. You can move a file by hardlinking
> >it and then unlinking the original name. If you do that with a
> >directory, at what point do you update its parent pointer? What
> >happens if you create TWO more hardlinks, and then unlink the original
> >name? Can you even *have* a single concept of a "real path" without it
> >basically just being symlinks in disguise?
>
> Shrug. Who says ".." is wired to the directory, and not the user's
> process context? Who says a wired to the directory ".." needs changing
> at any time except when its referring link count goes to 1? There are
> many choices here. Making those choices is a policy decision for the OS
> implementor, and they all have their costs and benefits.
>

Consider the situation I posed: start with one reference to the
directory, add two more, then remove the original. Where is its
parent? Is there any good way to handle that? And if you allow
hardlinking of directories at all, there's no reason to block this
particular sequence of operations. A naive reading of your description
is that the parent, in this situation, would remain unchanged - which
means the parent is some completely unrelated directory. Or, worse, it
could end up with a parent of itself, or a parent of its own child.

Are you SURE it can be well-defined?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: How do I pull the updated information from a tkinter form?

[Peter Otten]

Steve wrote:

> OK, I was closer than I thought.
> 
> Two weeks ago, the concept of tkinter and these forms were totally new to
> me
> as well as, about  two days ago, python list was totally new too. I
> somehow thought that "window.mainloop()" was supposed to be the last entry
> in the function, silly me...
> I did not think of returning the list.

Note that what I showed is probably not the best option.

Usually you would add a button that allows the user to trigger the write 
operation.

-- 
https://mail.python.org/mailman/listinfo/python-list

RE: How do I pull the updated information from a tkinter form?

[Steve]

At least it is working and lets me continue to develop the overall program.
I am working on the option to cancel the update if the user wants.

Since I do not know of a better way, is it not the best at the moment? (-:

My original design to edit the specifications by form was approaching 200
lines of code.  With the loops, probably now is 75.


Steve


FootNote:
If money does not grow on trees, then why do banks have branches?

-Original Message-
From: Python-list  On
Behalf Of Peter Otten
Sent: Monday, August 31, 2020 3:56 AM
To: python-list@python.org
Subject: RE: How do I pull the updated information from a tkinter form?

Steve wrote:

> OK, I was closer than I thought.
> 
> Two weeks ago, the concept of tkinter and these forms were totally new 
> to me as well as, about  two days ago, python list was totally new 
> too. I somehow thought that "window.mainloop()" was supposed to be the 
> last entry in the function, silly me...
> I did not think of returning the list.

Note that what I showed is probably not the best option.

Usually you would add a button that allows the user to trigger the write
operation.

--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Video file to subtitles file

[Betty Hollinshead]

ffmpeg mentioned elsewhere is the goto toolkit for all things video.
Subtitles, see: https://trac.ffmpeg.org/wiki/ExtractSubtitles

B.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Richard Damon]

On 8/31/20 3:35 AM, Chris Angelico wrote:
> On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson  wrote:
>>> Because of the ".." issue, it's not going to be as
>>> symmetric as hardlinking files is. You can move a file by hardlinking
>>> it and then unlinking the original name. If you do that with a
>>> directory, at what point do you update its parent pointer? What
>>> happens if you create TWO more hardlinks, and then unlink the original
>>> name? Can you even *have* a single concept of a "real path" without it
>>> basically just being symlinks in disguise?
>> Shrug. Who says ".." is wired to the directory, and not the user's
>> process context? Who says a wired to the directory ".." needs changing
>> at any time except when its referring link count goes to 1? There are
>> many choices here. Making those choices is a policy decision for the OS
>> implementor, and they all have their costs and benefits.
>>
> Consider the situation I posed: start with one reference to the
> directory, add two more, then remove the original. Where is its
> parent? Is there any good way to handle that? And if you allow
> hardlinking of directories at all, there's no reason to block this
> particular sequence of operations. A naive reading of your description
> is that the parent, in this situation, would remain unchanged - which
> means the parent is some completely unrelated directory. Or, worse, it
> could end up with a parent of itself, or a parent of its own child.
>
> Are you SURE it can be well-defined?
>
> ChrisA

EVERY  reference to the .. file link has to have a full path to that
link, either explicit with the reference of implicit via the current
working directory. That can define what is the parent. Yes, that says
that two references to the 'same' directory (same as in same inode, but
different paths) will find a different value for .. in it. So the
definition of .. can be well defined, even in the presence of multiple
parent directories.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Chris Angelico]

On Mon, Aug 31, 2020 at 9:57 PM Richard Damon  wrote:
>
> On 8/31/20 3:35 AM, Chris Angelico wrote:
> > On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson  wrote:
> >>> Because of the ".." issue, it's not going to be as
> >>> symmetric as hardlinking files is. You can move a file by hardlinking
> >>> it and then unlinking the original name. If you do that with a
> >>> directory, at what point do you update its parent pointer? What
> >>> happens if you create TWO more hardlinks, and then unlink the original
> >>> name? Can you even *have* a single concept of a "real path" without it
> >>> basically just being symlinks in disguise?
> >> Shrug. Who says ".." is wired to the directory, and not the user's
> >> process context? Who says a wired to the directory ".." needs changing
> >> at any time except when its referring link count goes to 1? There are
> >> many choices here. Making those choices is a policy decision for the OS
> >> implementor, and they all have their costs and benefits.
> >>
> > Consider the situation I posed: start with one reference to the
> > directory, add two more, then remove the original. Where is its
> > parent? Is there any good way to handle that? And if you allow
> > hardlinking of directories at all, there's no reason to block this
> > particular sequence of operations. A naive reading of your description
> > is that the parent, in this situation, would remain unchanged - which
> > means the parent is some completely unrelated directory. Or, worse, it
> > could end up with a parent of itself, or a parent of its own child.
> >
> > Are you SURE it can be well-defined?
> >
> > ChrisA
>
> EVERY  reference to the .. file link has to have a full path to that
> link, either explicit with the reference of implicit via the current
> working directory. That can define what is the parent. Yes, that says
> that two references to the 'same' directory (same as in same inode, but
> different paths) will find a different value for .. in it. So the
> definition of .. can be well defined, even in the presence of multiple
> parent directories.
>

That's incompatible with the normal meaning of "..", and it also
implies that any time you rename any directory, you have to scan all
of its children (recursively) to find any parent directory references
that need to change. I'm still not sure how this solves the problem -
it just pushes it to everything else, and you still have to have ".."
mean multiple things somehow.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Richard Damon]

On 8/31/20 9:00 AM, Chris Angelico wrote:
> On Mon, Aug 31, 2020 at 9:57 PM Richard Damon  
> wrote:
>> On 8/31/20 3:35 AM, Chris Angelico wrote:
>>> On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson  wrote:
> Because of the ".." issue, it's not going to be as
> symmetric as hardlinking files is. You can move a file by hardlinking
> it and then unlinking the original name. If you do that with a
> directory, at what point do you update its parent pointer? What
> happens if you create TWO more hardlinks, and then unlink the original
> name? Can you even *have* a single concept of a "real path" without it
> basically just being symlinks in disguise?
 Shrug. Who says ".." is wired to the directory, and not the user's
 process context? Who says a wired to the directory ".." needs changing
 at any time except when its referring link count goes to 1? There are
 many choices here. Making those choices is a policy decision for the OS
 implementor, and they all have their costs and benefits.

>>> Consider the situation I posed: start with one reference to the
>>> directory, add two more, then remove the original. Where is its
>>> parent? Is there any good way to handle that? And if you allow
>>> hardlinking of directories at all, there's no reason to block this
>>> particular sequence of operations. A naive reading of your description
>>> is that the parent, in this situation, would remain unchanged - which
>>> means the parent is some completely unrelated directory. Or, worse, it
>>> could end up with a parent of itself, or a parent of its own child.
>>>
>>> Are you SURE it can be well-defined?
>>>
>>> ChrisA
>> EVERY  reference to the .. file link has to have a full path to that
>> link, either explicit with the reference of implicit via the current
>> working directory. That can define what is the parent. Yes, that says
>> that two references to the 'same' directory (same as in same inode, but
>> different paths) will find a different value for .. in it. So the
>> definition of .. can be well defined, even in the presence of multiple
>> parent directories.
>>
> That's incompatible with the normal meaning of "..", and it also
> implies that any time you rename any directory, you have to scan all
> of its children (recursively) to find any parent directory references
> that need to change. I'm still not sure how this solves the problem -
> it just pushes it to everything else, and you still have to have ".."
> mean multiple things somehow.
>
> ChrisA

The . and .. entries in a directory don't need to be 'real' entries
added to the directory using up directory slots in the directory, but
pseudo entries created by the file system when reading a directory. To
read a directory, you need to specify it (how else do you say you want
to read it), and the meaning of . and .. can be derived from the path
used to read the directory.

And yes, this means that a given directory, reachable by multiple paths,
may give different values for .. (or .) based on which path you came to
it from.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Chris Angelico]

On Tue, Sep 1, 2020 at 2:40 AM Richard Damon  wrote:
>
> On 8/31/20 9:00 AM, Chris Angelico wrote:
> > That's incompatible with the normal meaning of "..", and it also
> > implies that any time you rename any directory, you have to scan all
> > of its children (recursively) to find any parent directory references
> > that need to change. I'm still not sure how this solves the problem -
> > it just pushes it to everything else, and you still have to have ".."
> > mean multiple things somehow.
> >
> > ChrisA
>
> The . and .. entries in a directory don't need to be 'real' entries
> added to the directory using up directory slots in the directory, but
> pseudo entries created by the file system when reading a directory. To
> read a directory, you need to specify it (how else do you say you want
> to read it), and the meaning of . and .. can be derived from the path
> used to read the directory.

You can open a directory (same as you open a file), and then you have
an open file descriptor. You can open something relative to something
else. And you can chroot in between those two operations, which would
mean that there is no complete path that references what you are
opening.

> And yes, this means that a given directory, reachable by multiple paths,
> may give different values for .. (or .) based on which path you came to
> it from.

That would basically violate the concept of hardlinks, which is that
they have the same content regardless of how you access them. What
you're suggesting is far better handled by symlinks.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Barry Scott]

> On 31 Aug 2020, at 17:38, Richard Damon  wrote:
> 
> On 8/31/20 9:00 AM, Chris Angelico wrote:
>> On Mon, Aug 31, 2020 at 9:57 PM Richard Damon  
>> wrote:
>>> On 8/31/20 3:35 AM, Chris Angelico wrote:
 On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson  wrote:
>> Because of the ".." issue, it's not going to be as
>> symmetric as hardlinking files is. You can move a file by hardlinking
>> it and then unlinking the original name. If you do that with a
>> directory, at what point do you update its parent pointer? What
>> happens if you create TWO more hardlinks, and then unlink the original
>> name? Can you even *have* a single concept of a "real path" without it
>> basically just being symlinks in disguise?
> Shrug. Who says ".." is wired to the directory, and not the user's
> process context? Who says a wired to the directory ".." needs changing
> at any time except when its referring link count goes to 1? There are
> many choices here. Making those choices is a policy decision for the OS
> implementor, and they all have their costs and benefits.
> 
 Consider the situation I posed: start with one reference to the
 directory, add two more, then remove the original. Where is its
 parent? Is there any good way to handle that? And if you allow
 hardlinking of directories at all, there's no reason to block this
 particular sequence of operations. A naive reading of your description
 is that the parent, in this situation, would remain unchanged - which
 means the parent is some completely unrelated directory. Or, worse, it
 could end up with a parent of itself, or a parent of its own child.
 
 Are you SURE it can be well-defined?
 
 ChrisA
>>> EVERY  reference to the .. file link has to have a full path to that
>>> link, either explicit with the reference of implicit via the current
>>> working directory. That can define what is the parent. Yes, that says
>>> that two references to the 'same' directory (same as in same inode, but
>>> different paths) will find a different value for .. in it. So the
>>> definition of .. can be well defined, even in the presence of multiple
>>> parent directories.
>>> 
>> That's incompatible with the normal meaning of "..", and it also
>> implies that any time you rename any directory, you have to scan all
>> of its children (recursively) to find any parent directory references
>> that need to change. I'm still not sure how this solves the problem -
>> it just pushes it to everything else, and you still have to have ".."
>> mean multiple things somehow.
>> 
>> ChrisA
> 
> The . and .. entries in a directory don't need to be 'real' entries
> added to the directory using up directory slots in the directory, but
> pseudo entries created by the file system when reading a directory. To
> read a directory, you need to specify it (how else do you say you want
> to read it), and the meaning of . and .. can be derived from the path
> used to read the directory.
> 
> And yes, this means that a given directory, reachable by multiple paths,
> may give different values for .. (or .) based on which path you came to
> it from.

I'm intrigued.

How are you adding a second path that shows this mutating ".." ?
I tried with a symlink and that did not change the ".." inode.
Do you mean that I can do this with a bind mount?

Barry


> 
> -- 
> Richard Damon
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Richard Damon]

On 8/31/20 1:07 PM, Barry Scott wrote:
>
> I'm intrigued.
>
> How are you adding a second path that shows this mutating ".." ?
> I tried with a symlink and that did not change the ".." inode.
> Do you mean that I can do this with a bind mount?
>
> Barry
>
This is based on a hypothetical OS that allows creating hard-links to
directories, just like to files. Because current *nix system don't do it
this way, they don't allow hard-links to directories because it does
cause this sort of issue.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Richard Damon]

On 8/31/20 12:49 PM, Chris Angelico wrote:
> On Tue, Sep 1, 2020 at 2:40 AM Richard Damon  wrote:
>> On 8/31/20 9:00 AM, Chris Angelico wrote:
>>> That's incompatible with the normal meaning of "..", and it also
>>> implies that any time you rename any directory, you have to scan all
>>> of its children (recursively) to find any parent directory references
>>> that need to change. I'm still not sure how this solves the problem -
>>> it just pushes it to everything else, and you still have to have ".."
>>> mean multiple things somehow.
>>>
>>> ChrisA
>> The . and .. entries in a directory don't need to be 'real' entries
>> added to the directory using up directory slots in the directory, but
>> pseudo entries created by the file system when reading a directory. To
>> read a directory, you need to specify it (how else do you say you want
>> to read it), and the meaning of . and .. can be derived from the path
>> used to read the directory.
> You can open a directory (same as you open a file), and then you have
> an open file descriptor. You can open something relative to something
> else. And you can chroot in between those two operations, which would
> mean that there is no complete path that references what you are
> opening.
The file descriptor could remember the path used to get to it. chroot
shows that .. needs to be somewhat special, as it needs to go away for
anyone that . is their current root.
>
>> And yes, this means that a given directory, reachable by multiple paths,
>> may give different values for .. (or .) based on which path you came to
>> it from.
> That would basically violate the concept of hardlinks, which is that
> they have the same content regardless of how you access them. What
> you're suggesting is far better handled by symlinks.
>
> ChrisA

I see no problem with it being a hardlink, and in fact, executables know
the name they were executed by, so directories  knowing the path isn't
that different. The key differnce between a hardlink and a symlink is
that hardlinks maintain existance, and always point to something that
exists (things know how many hardlinks refer to them). symlinks don't
reference the actual file object, but the symbolic path to it, which may
or may not actually exist, and who doesn't know such a link exists.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Symlinks already present

[Chris Angelico]

On Tue, Sep 1, 2020 at 5:08 AM Richard Damon  wrote:
> The file descriptor could remember the path used to get to it. chroot
> shows that .. needs to be somewhat special, as it needs to go away for
> anyone that . is their current root.

But my point is that there might not actually *be* a valid path that
gets you to a file descriptor. It can't remember something that
doesn't exist. (And it's pretty impractical to do that even if it
does.)

> I see no problem with it being a hardlink, and in fact, executables know
> the name they were executed by, so directories  knowing the path isn't
> that different.

Actually no, they don't. They are all taught, and being taught,
believe, that their first argument is their name.

> The key differnce between a hardlink and a symlink is
> that hardlinks maintain existance, and always point to something that
> exists (things know how many hardlinks refer to them). symlinks don't
> reference the actual file object, but the symbolic path to it, which may
> or may not actually exist, and who doesn't know such a link exists.

Symlinks refer to a path, which may be relative. Hardlinks refer to an
inode (or whatever other way you choose to identify an actual file's
contents). It's entirely possible to have an open file or directory
that no longer has any actual path referring to it; in fact, things
don't know how many hardlinks refer to them, just how many references
there are.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Another 2 to 3 mail encoding problem

[Peter J. Holzer]

On 2020-08-27 09:34:47 +0100, Chris Green wrote:
> Peter J. Holzer  wrote:
> > The problem is that the message contains a '\ufeff' character (byte
> > order mark) where email/generator.py expects only ASCII characters.
> > 
> > I see two possible reasons for this:
[...]
> > Both reasons are weird.
[...]
> > But then you haven't shown where msg comes from. How do you parse the
> > message to get "msg"?
> > 
> > Can you construct a minimal test message which triggers the bug?
> > 
> Yes, simply sending myself an E-Mail with (for example) accented
> characters triggers the error.

Ok. So it's not a specific message, but any mail with accented
characters.

Since Python's mailbox module handles mails with accented characters
just fine (I've processed thousands of mails with it), the bug is almost
certainly in your program. And, as I explained above, almost certainly
in the part which you didn't show us.

Can you reduce your program to the minimum which still triggers the bug
and post the result here?

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list