In article ,
Cameron Simpson wrote:
>
>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
In article ,
Grant Edwards wrote:
>On 2020-09-01, Richard Damon wrote:
>
>> Remember, we are talking about a hypothetical OS that handles hardlinks
>> to directories, and defines that .. will point to the parent used to
>> come to it, NOT just having current *NIX allowing hardlinks to
>>
On 9/3/20, Greg Ewing wrote:
> On 2/09/20 6:55 am, Eryk Sun wrote:
>> According to POSIX (st_dev, st_ino), it's the same directory, yet the
>> ".." entry evaluates depending on the path parsing context:
>>
>> >>> os.lstat('test1/spam/..').st_ino == os.lstat('test1').st_ino
>> True
>>
On 2/09/20 6:55 am, Eryk Sun wrote:
According to POSIX (st_dev, st_ino), it's the same directory, yet the
".." entry evaluates depending on the path parsing context:
>>> os.lstat('test1/spam/..').st_ino == os.lstat('test1').st_ino
True
>>> os.lstat('test2/spam/..').st_ino ==
On 2020-09-01, Richard Damon wrote:
> My research says that Unix System V allowed them, but restricted them to
> super users, to avoid the bigger problems with them. I don't know how it
> handle the issue of ..
SunOS-3/4 (a BSD 4.x derivative) allowed them, but restricted them to
root. It did
On 01Sep2020 18:42, Grant Edwards wrote:
>On 2020-09-01, Richard Damon wrote:
>> Remember, we are talking about a hypothetical OS that handles
>> hardlinks
>> to directories, and defines that .. will point to the parent used to
>> come to it, NOT just having current *NIX allowing hardlinks to
On 9/1/20 9:03 AM, Chris Angelico wrote:
> On Tue, Sep 1, 2020 at 10:57 PM Richard Damon
> wrote:
>> On 8/31/20 6:05 PM, Chris Angelico wrote:
>>> 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
On 9/1/20, Chris Angelico wrote:
> On Wed, Sep 2, 2020 at 4:55 AM Eryk Sun wrote:
>
>> "test2/spam" is a bind mount for "test1/spam", and note that `mount
>> --bind` in Linux is a namespace operation, i.e. it's not a new device:
>>
>> >>> os.lstat('test1/spam').st_dev ==
On Wed, Sep 2, 2020 at 4:55 AM Eryk Sun wrote:
>
> On 9/1/20, Chris Angelico wrote:
> >
> > Also, even if all that could be solved, I don't like the idea that
> > reading the same directory from two different sources leads to
> > different results. Is it really the same directory if reading it
On 2020-09-01, Richard Damon wrote:
> Remember, we are talking about a hypothetical OS that handles hardlinks
> to directories, and defines that .. will point to the parent used to
> come to it, NOT just having current *NIX allowing hardlinks to
> directories with no remediation of the issues
On 9/1/20, Chris Angelico wrote:
>
> Also, even if all that could be solved, I don't like the idea that
> reading the same directory from two different sources leads to
> different results. Is it really the same directory if reading it in
> different ways gives different results?
What's your
On Tue, Sep 1, 2020 at 10:57 PM Richard Damon wrote:
>
> On 8/31/20 6:05 PM, Chris Angelico wrote:
> > 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
On 8/31/20 6:05 PM, Chris Angelico wrote:
> 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
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
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
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
> 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 ".."
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
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
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 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 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
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
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
On 27Jul2020 20:20, Termoregolato wrote:
>Il 26/07/20 20:39, Dennis Lee Bieber ha scritto:
>>Since symbolic links are essentially just short files containing the
>>path to the eventual target file/directory, with an OS flag that the file
>>is a link
>
>Yes, I use them massively to give to a lot
On 27Jul2020 22:19, Grant Edwards wrote:
>On 2020-07-27, Termoregolato wrote:
>> Il 26/07/20 22:47, dn ha scritto:
>>> Thus, compare the results of the two calls to detect a difference.
>>
>> I will try also another way, If I don't err symlinks and original
>> directory have the same inode
On 2020-08-08 at 01:58:13 +0200,
Termoregolato wrote:
> me@debsrv:~/tmp/test$ stat --format=%i /home/me/mydir
> 18481153
Try ls -i. :-)
--
https://mail.python.org/mailman/listinfo/python-list
Il 27/07/20 20:37, Chris Angelico ha scritto:
Unfortunately there's no real way to shortcut this if you just want to
check one target directory. You'd still have to readlink() every
symlink to try to find them.
Sorry for 10 days of delay (hardware problems at home). Yes, that is.
It's a mode
Il 28/07/20 02:50, Dennis Lee Bieber ha scritto:
inode numbers apply for HARD LINKS
Thanks
--
Pastrano
con un altro account
--
https://mail.python.org/mailman/listinfo/python-list
Il 28/07/20 00:19, Grant Edwards ha scritto:
You err.
I read it, I had to test. In effects, it was simple to test.
me@debsrv:~/tmp/test$ ln -s /home/me/mydir aaa
me@debsrv:~/tmp/test$ ln -s /home/me/mydir bbb
me@debsrv:~/tmp/test$ ls
aaa bbb
me@debsrv:~/tmp/test$ stat --format=%i
On 2020-07-27, Termoregolato wrote:
> Il 26/07/20 22:47, dn ha scritto:
>
>> Thus, compare the results of the two calls to detect a difference.
>
> I will try also another way, If I don't err symlinks and original
> directory have the same inode number (I talk about Linux, where I'm
> using
Il 26/07/20 22:47, dn ha scritto:
Thus, compare the results of the two calls to detect a difference.
I will try also another way, If I don't err symlinks and original
directory have the same inode number (I talk about Linux, where I'm
using the application). I've a lot of directories like
On 2020-07-27 at 20:20:08 +0200,
Termoregolato wrote:
> Il 26/07/20 20:39, Dennis Lee Bieber ha scritto:
>
> > Since symbolic links are essentially just short files containing the
> > path to the eventual target file/directory, with an OS flag that the file
> > is a link
>
> Yes, I use them
On Tue, Jul 28, 2020 at 4:26 AM Termoregolato wrote:
>
> Il 26/07/20 20:39, Dennis Lee Bieber ha scritto:
>
> > Since symbolic links are essentially just short files containing the
> > path to the eventual target file/directory, with an OS flag that the file
> > is a link
>
> Yes, I use them
Il 26/07/20 20:39, Dennis Lee Bieber ha scritto:
Since symbolic links are essentially just short files containing the
path to the eventual target file/directory, with an OS flag that the file
is a link
Yes, I use them massively to give to a lot of directories a kind of
order, depending on
On 27/07/2020 00:56, Termoregolato wrote:
There is any way to check if a directory is already symlinked, without
controlling every symlink viewing the link? That is a bit time
consuming, due I've two or three directory that can have a new symlink,
but I've to check on a list of 20-3
Il 26/07/20 15:19, Barry ha scritto:
No. None.
Sob :-) But thanks for confirm.
Don’t you have control of the code that is adding the symlinks?
No, so I must traverse the directories where symlinks are, to
deduplicate them. There are some modes to minimize the work, but that
way could be
> On 26 Jul 2020, at 14:03, Termoregolato wrote:
>
> There is any way to check if a directory is already symlinked,
No. None.
> without controlling every symlink viewing the link? That is a bit time
> consuming, due I've two or three directory that can have a new symlink, but
> I've to
There is any way to check if a directory is already symlinked, without
controlling every symlink viewing the link? That is a bit time
consuming, due I've two or three directory that can have a new symlink,
but I've to check on a list of 20-3 symlinks to delete it and avoid
duplicates...
39 matches
Mail list logo
