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 direc
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 pare
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,
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
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
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
>>>
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
> >>>
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
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 direc
> 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 ".." issu
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 all
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 chi
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 pa
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.
14 matches
Mail list logo
