I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to
be mounted with suid working. It seems I should be able to do something
like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried). I also tried "nonosuid",
but that doesn't work either.

(*) "mount" is notorious for giving "Ken Thompson style" error messages
(i.e., the only error message you'll ever need is "No").

Notes:
1) Googling finds lots of stuff about how (and why) to mount nosuid,
but not the opposite.
2) (Obviously) I'm not interested in any solutions that need a time
machine or involve editing /etc/fstab or that involve un-mounting
it and mounting it over from scratch.

It seems there should be a way with remount. "man mount" talks a fair bit
about using "--bind" as an alternative to "-o remount", but I did not
follow that very well. I've used "-o remount" many times in the past,
successfully.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Security

On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:

> I have encountered an interesting situation. I have a USB disk drive
> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
> and it is mounted with "nosuid" (which is normal). But I would like it to
> be mounted with suid working. It seems I should be able to do something
> like:
>
> # mount -o remount,suid /dev/sdb1
>
> but that generates err msg "invalid option or not mounted" (*) (as does
> every variation of the above that I've tried).

That's strange. mount(8) explicitly names "suid" as an option, with the
explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.

BUT.... suid (like a number of other options) only applies iff the underlying
filesystem supports set-user-identifier and set-group-identifier bits. Some
filesystems don't (like FAT and NTFS-based filesystems).

Are you trying to mount a non-unix filesystem?

> I also tried "nonosuid",
> but that doesn't work either.
>
> (*) "mount" is notorious for giving "Ken Thompson style" error messages
> (i.e., the only error message you'll ever need is "No").

[snip]

HTH
--
Lew Pitcher
"In Skills We Trust"

In article <uvud53$30gsv$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
>
>> I have encountered an interesting situation. I have a USB disk drive
>> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
>> and it is mounted with "nosuid" (which is normal). But I would like it to
>> be mounted with suid working. It seems I should be able to do something
>> like:
>>
>> # mount -o remount,suid /dev/sdb1
>>
>> but that generates err msg "invalid option or not mounted" (*) (as does
>> every variation of the above that I've tried).
>
>That's strange. mount(8) explicitly names "suid" as an option, with the
>explanation:
> suid Allow set-user-identifier or set-group-identifier bits to take
> effect.

OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.

Turns out that it works if I use the mount point rather than the device.
I.e.,:

# mount -o remount,suid /path/to/wherever/it/was/mounted

works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount
point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.

--
Kenny, I'll ask you to stop using quotes of mine as taglines.

- Rick C Hodgin -

Kenny McCormack <gazelle@shell.xmission.com> wrote at 20:39 this Friday (GMT):
> In article <uvud53$30gsv$1@dont-email.me>,
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
>>
>>> I have encountered an interesting situation. I have a USB disk drive
>>> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
>>> and it is mounted with "nosuid" (which is normal). But I would like it to
>>> be mounted with suid working. It seems I should be able to do something
>>> like:
>>>
>>> # mount -o remount,suid /dev/sdb1
>>>
>>> but that generates err msg "invalid option or not mounted" (*) (as does
>>> every variation of the above that I've tried).
>>
>>That's strange. mount(8) explicitly names "suid" as an option, with the
>>explanation:
>> suid Allow set-user-identifier or set-group-identifier bits to take
>> effect.
>
> OK - that's my reason for posting. To find out that it "should" work.
> That there is an option for it.
>
> Turns out that it works if I use the mount point rather than the device.
> I.e.,:
>
> # mount -o remount,suid /path/to/wherever/it/was/mounted
>
> works as expected. Strange, because for as long as I've been using
> "mount", it has always been OK to use either the device name or the mount
> point (for a mounted device - i.e., once it has been mounted); they are
> basically synonymous. But this seems to be an exception.

Strange, I thought remount worked with the block device..
--
user <candycane> is generated from /dev/urandom

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:

> Kenny McCormack <gazelle@shell.xmission.com> wrote at 20:39 this Friday (GMT):
>> In article <uvud53$30gsv$1@dont-email.me>,
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
>>>
>>>> I have encountered an interesting situation. I have a USB disk drive
>>>> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
>>>> and it is mounted with "nosuid" (which is normal). But I would like it to
>>>> be mounted with suid working. It seems I should be able to do something
>>>> like:
>>>>
>>>> # mount -o remount,suid /dev/sdb1
>>>>
>>>> but that generates err msg "invalid option or not mounted" (*) (as does
>>>> every variation of the above that I've tried).
>>>
>>>That's strange. mount(8) explicitly names "suid" as an option, with the
>>>explanation:
>>> suid Allow set-user-identifier or set-group-identifier bits to take
>>> effect.
>>
>> OK - that's my reason for posting. To find out that it "should" work.
>> That there is an option for it.
>>
>> Turns out that it works if I use the mount point rather than the device.
>> I.e.,:
>>
>> # mount -o remount,suid /path/to/wherever/it/was/mounted
>>
>> works as expected. Strange, because for as long as I've been using
>> "mount", it has always been OK to use either the device name or the mount
>> point (for a mounted device - i.e., once it has been mounted); they are
>> basically synonymous. But this seems to be an exception.
>
> Strange, I thought remount worked with the block device..

I haven't used remount much but I'll make one observation... A block
device can be mounted in more than one place, so it would make sense for
remount to need the mount point rather than the device to be sure of
what needs to be remounted.

--
Ben.

In article <uvvcrr$3euft$2@dont-email.me>,
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
....
>> Turns out that it works if I use the mount point rather than the device.
>> I.e.,:
>>
>> # mount -o remount,suid /path/to/wherever/it/was/mounted
>>
>> works as expected. Strange, because for as long as I've been using
>> "mount", it has always been OK to use either the device name or the mount
>> point (for a mounted device - i.e., once it has been mounted); they are
>> basically synonymous. But this seems to be an exception.
>
>
>Strange, I thought remount worked with the block device..

Actually, it is pretty clear at this point (moreso now than when I started
this thread - that is a Good Thing. I've learned some things from having
launched this thread) that a "mount" is a data structure associated with a
directory, not with a device. The device is one of the properties of the
data structure (that isn't necessarily present, and isn't present in all
mounts).

So, it makes sense that you should have to specify the directory (referred
to as "the target" in the man pages) in most cases. It turns out that the
one exception to this - umount-ing - is actually an historical anomaly.
According to "man 2 umount", umount used to be "umount(device)", but then
they changed it to "umount(directory)" (for a while both were supported, at
the system call level, but then the "device" form was dropped). So, I
assume that, as a courtesy and for backward compatibility, the "umount"
program substitutes the device name with the directory name before invoking
the system call.

--
Most Southerners interest in, knowledge of, and participation in politics begins with
and ends with: Screw the blacks. If a guy is onboard with that, he's our guy!

Get them back in chains where they belong!

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote at 00:54 this Sunday (GMT):
> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
> writes:
>
>> Kenny McCormack <gazelle@shell.xmission.com> wrote at 20:39 this Friday (GMT):
>>> In article <uvud53$30gsv$1@dont-email.me>,
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>>On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:
>>>>
>>>>> I have encountered an interesting situation. I have a USB disk drive
>>>>> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
>>>>> and it is mounted with "nosuid" (which is normal). But I would like it to
>>>>> be mounted with suid working. It seems I should be able to do something
>>>>> like:
>>>>>
>>>>> # mount -o remount,suid /dev/sdb1
>>>>>
>>>>> but that generates err msg "invalid option or not mounted" (*) (as does
>>>>> every variation of the above that I've tried).
>>>>
>>>>That's strange. mount(8) explicitly names "suid" as an option, with the
>>>>explanation:
>>>> suid Allow set-user-identifier or set-group-identifier bits to take
>>>> effect.
>>>
>>> OK - that's my reason for posting. To find out that it "should" work.
>>> That there is an option for it.
>>>
>>> Turns out that it works if I use the mount point rather than the device.
>>> I.e.,:
>>>
>>> # mount -o remount,suid /path/to/wherever/it/was/mounted
>>>
>>> works as expected. Strange, because for as long as I've been using
>>> "mount", it has always been OK to use either the device name or the mount
>>> point (for a mounted device - i.e., once it has been mounted); they are
>>> basically synonymous. But this seems to be an exception.
>>
>> Strange, I thought remount worked with the block device..
>
> I haven't used remount much but I'll make one observation... A block
> device can be mounted in more than one place, so it would make sense for
> remount to need the mount point rather than the device to be sure of
> what needs to be remounted.

Oh, I never considered that. I don't think I've seen multiple mount
points before.
--
user <candycane> is generated from /dev/urandom

On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:

> I don't think I've seen multiple mount points before

Linux calls them “bind mounts”. Very handy, for example with containers,
to give the guest userland visibility into selected parts of the host
filesystem.

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:11 this Monday (GMT):
> On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:
>
>> I don't think I've seen multiple mount points before
>
> Linux calls them “bind mounts”. Very handy, for example with containers,
> to give the guest userland visibility into selected parts of the host
> filesystem.

Makes sense, since you can't hard link directories.
--
user <candycane> is generated from /dev/urandom

On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
<candycanearter07@candycanearter07.nomail.afraid> wrote in
<v12on9$ihfm$6@dont-email.me>:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:11 this Monday (GMT):
>> On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:
>>
>>> I don't think I've seen multiple mount points before
>>
>> Linux calls them “bind mounts”. Very handy, for example with
>> containers,
>> to give the guest userland visibility into selected parts of the host
>> filesystem.
>
>
> Makes sense, since you can't hard link directories.

Sometimes, you can, depending on OS and filesystem:

https://jameshunt.us/writings/linking-dirs-in-macos/

IIRC, Apple's Time Machine uses this capability.

BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.

bind mounts are different, because they don't alter the filesystem
structure. Otherwise, you might end up with an un-fsck-able
filesystem.

--
-v

On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:

> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
> <candycanearter07@candycanearter07.nomail.afraid> wrote in
> <v12on9$ihfm$6@dont-email.me>:
>
>> ... you can't hard link directories.
>
> Sometimes, you can, depending on OS and filesystem:
>
> https://jameshunt.us/writings/linking-dirs-in-macos/
>
> IIRC, Apple's Time Machine uses this capability.
>
> BTW, I'm not mentioning this because I think it's a good idea;
> the Unix puritan in me abhors hard-linked directories.

They are a very, very, very, very bad idea. And completely unnecessary.

> bind mounts are different, because they don't alter the filesystem
> structure. Otherwise, you might end up with an un-fsck-able
> filesystem.

Fun fact: Linux doesn’t actually distinguish between different mounts of
the same filesystem (in the sense that one is the “original” mount and the
others are not). That is, you can keep a later “bind” mount, and remove
the original non-“bind” mount, and it still works.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>
>> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>> <v12on9$ihfm$6@dont-email.me>:
>>
>>> ... you can't hard link directories.
>>
>> Sometimes, you can, depending on OS and filesystem:
>>
>> https://jameshunt.us/writings/linking-dirs-in-macos/
>>
>> IIRC, Apple's Time Machine uses this capability.
>>
>> BTW, I'm not mentioning this because I think it's a good idea;
>> the Unix puritan in me abhors hard-linked directories.
>
> They are a very, very, very, very bad idea. And completely unnecessary.

Why are they a bad idea? Can you show examples? I can't see it. Thanks!

In article <87plu14zrw.fsf@tudado.org>,
Johanne Fairchild <jfairchild@tudado.org> wrote:
....
>> They are a very, very, very, very bad idea. And completely unnecessary.
>
>Why are they a bad idea? Can you show examples? I can't see it. Thanks!

The poster who used too many "Very"s is a known crank.

Generally, the more "Very"s you use, the worse is your argument.

Or, as Mark Twain once put it:

A young writer asked me how to edit his writing. I told him that he
should go through and replace every occurrence of the word "very" with
the word "damn". His editor would then remove every occurrence of the
later word, and then things would be as they should be.

So at our house, with this story in mind, whenever we use the word "very"
in conversation, we immediately change it to "damn". So, the above would
be:

They are a damn, damn, damn, damn bad idea. And completely unnecessary.

and after editing:

They are a bad idea. And completely unnecessary.

--
Many (most?) Trump voters voted for him because they thought if they
supported Trump enough, they'd get to *be* Trump.

Similarly, Trump believes that if *he* praises Putin enough, he'll get to *be* Putin.

On Sat, 04 May 2024 07:50:11 -0300
Johanne Fairchild <jfairchild@tudado.org> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>>
>>> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
>>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>>> <v12on9$ihfm$6@dont-email.me>:
>>>
>>>> ... you can't hard link directories.
>>>
>>> Sometimes, you can, depending on OS and filesystem:
>>>
>>> https://jameshunt.us/writings/linking-dirs-in-macos/
>>>
>>> IIRC, Apple's Time Machine uses this capability.
>>>
>>> BTW, I'm not mentioning this because I think it's a good idea;
>>> the Unix puritan in me abhors hard-linked directories.
>>
>> They are a very, very, very, very bad idea. And completely unnecessary.
>
>Why are they a bad idea? Can you show examples? I can't see it. Thanks!

Probably because there isn't much point (not that IMO there's much point to
hard links anyway) as when you delete the directory you'll delete all the
files inside but the now empty directory will still exist wherever its hard link
is.

On 2024-05-04, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Probably because there isn't much point (not that IMO there's much point to
> hard links anyway) as when you delete the directory you'll delete all the
> files inside but the now empty directory will still exist wherever its hard link
> is.

This problem happens anyway when one or more processes have that
directory as their root or cwd, referring to it by open inode.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sat, 04 May 2024 07:50:11 -0300, Johanne Fairchild wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>>
>>> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
>>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>>> <v12on9$ihfm$6@dont-email.me>:
>>>
>>>> ... you can't hard link directories.
>>>
>>> Sometimes, you can, depending on OS and filesystem:
>>>
>>> https://jameshunt.us/writings/linking-dirs-in-macos/
>>>
>>> IIRC, Apple's Time Machine uses this capability.
>>>
>>> BTW, I'm not mentioning this because I think it's a good idea;
>>> the Unix puritan in me abhors hard-linked directories.
>>
>> They are a very, very, very, very bad idea. And completely unnecessary.
>
> Why are they a bad idea? Can you show examples? I can't see it. Thanks!

A hardlink introduces an undetectable cyclicity in the underlying filesystem.

It must reference an inode within a specific filesystem (and, thus, cannot
cross filesystems or mountpoints), and (unlike softlinks) has no other
distinguishing feature. This means that you can only determine if a
/directory/ hardlink has introduced a cyclical reference by actually
traversing the hardlinked directory structures until you return to the
starting link.

On the other hand, you can detect both softlinks and bind mounts without
directory traversal. A softlink inode contains a very specific flag to
indicate that it contains a softlink, and the system records a bind mount
in the its public mount records.

--
Lew Pitcher
"In Skills We Trust"

In article <v15gcp$18g38$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
....
>Probably because there isn't much point (not that IMO there's much point to
>hard links anyway) ...

Without hard links, you could not have a Unix filesystem.

So, you do need them.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/BestCLCPostEver

On Sat, 04 May 2024 14:39:28 +0000, Lew Pitcher wrote:

> On Sat, 04 May 2024 07:50:11 -0300, Johanne Fairchild wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>>>
>>>> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
>>>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>>>> <v12on9$ihfm$6@dont-email.me>:
>>>>
>>>>> ... you can't hard link directories.
>>>>
>>>> Sometimes, you can, depending on OS and filesystem:
>>>>
>>>> https://jameshunt.us/writings/linking-dirs-in-macos/
>>>>
>>>> IIRC, Apple's Time Machine uses this capability.
>>>>
>>>> BTW, I'm not mentioning this because I think it's a good idea;
>>>> the Unix puritan in me abhors hard-linked directories.
>>>
>>> They are a very, very, very, very bad idea. And completely unnecessary.
>>
>> Why are they a bad idea? Can you show examples? I can't see it. Thanks!
>
> A hardlink introduces an undetectable cyclicity in the underlying filesystem.
>
> It must reference an inode within a specific filesystem (and, thus, cannot
> cross filesystems or mountpoints), and (unlike softlinks) has no other
> distinguishing feature. This means that you can only determine if a
> /directory/ hardlink has introduced a cyclical reference by actually
> traversing the hardlinked directory structures until you return to the
> starting link.

Note that unix filesystems support a limited, controlled subset of hardlinks:
the "." and ".." directories found in each directory. The OS controls the
creation and deletion of /these/ hardlinks from within, as part of the mkdir(2)
and rmdir(2) syscalls. And, the only cyclical hardlink (that I know of, anyway)
lives as "/..", which links to itself.

As for a cyclical hardlink, imagine the following:
# Build a disposable directory
mkdir /tmp/dumb

# Populate the disposable directory with a cyclical hardlink
ln /tmp/dumb /tmp/dumb/dumber

# Now, let's empty the disposable directory
rm -rf /tmp/dumb

What does the "rm -rf" do when that "ln /tmp/dumb /tmp/dumb/dumber" actually
creates a hardlink from /tmp/dumb/dumber to /tmp/dumb ?

--
Lew Pitcher
"In Skills We Trust"

On 2024-05-04, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> A hardlink introduces an undetectable cyclicity in the underlying filesystem.

You mean, trouble some cyclicity that is detectable with a lot of
annoying fuss, that has to be done wherever the filesystem is being
recursively traversed.

> It must reference an inode within a specific filesystem (and, thus, cannot
> cross filesystems or mountpoints), and (unlike softlinks) has no other
> distinguishing feature. This means that you can only determine if a
> /directory/ hardlink has introduced a cyclical reference by actually
> traversing the hardlinked directory structures until you return to the
> starting link.

If you keep the path of inodes you have visited in order to reach a
certain directory, then you can detect a cycle by checking whether a
newly visited directory is one of the elements of the path. Since
paths are reasonably short, you don't need any fancy hash data structure
for this; a linear scan will work fine in most cases, and so you can
represent the path as a linked list that is allocated on the stack,
if working in C.

void recurse(..., visited_node *parent)
{
visited_node current = { .up = parent };
// ...
}

The cyclic check is simply chasing the parent->up pointers to see if any
of the visited nodes is the same object as the newly visited one.

The problem is:

1. Everything that performs traversals of the filesystem now *has* to do
this, or risk being stuck in a loop. There is a bad habit in the
Unix programming culture of people rolling their own filesystem
traversal functions. Some of them would get it wrong, ending up in
infinite loops.

2. Even if you have cycle detection, you still have the problem that
every recursive traversal performed anywhere runs the risk of
potentially visiting the entire filesystem!

Directory hard links could be restricted to being downward-only. So that
is to say, if you create a P/C -> D hard link, then X is required to be
a descendant of P, such as P/X/Y/D.

To check that without race conditions, the kernel would have to lock
down all operations on that filesystem during the link operation.
Starting at D, it could navigate the parent .. links until it hits
the root directory, P, or hits a mount point crossing. If it finds P,
then it can conclude that the link can be made. (Without TOCtoTOU
if things are properly locked down.)

Holding a lock over a complex operation like that could open an avenue
to a DOS attack against the filesystem. Imagine a swarm of threads doing
directory linking operations, causing that lock to be excessively held.

The descendant restriction would make directory hardlinks inapplicable
to some people's use cases. (Oh well, they'd have to use symlinks
for those situations.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Sat, 4 May 2024 14:40:54 -0000 (UTC)
gazelle@shell.xmission.com (Kenny McCormack) wrote:
>In article <v15gcp$18g38$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>....
>>Probably because there isn't much point (not that IMO there's much point to
>>hard links anyway) ...
>
>Without hard links, you could not have a Unix filesystem.

Why not? If you meant "." and ".." FAT copes without having these as actual
filesystem entries - they simply get interpreted by the path string parsing
system. I'm not even sure if NTFS has them as hard links either.

On Sat, 04 May 2024 07:50:11 -0300, Johanne Fairchild wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>>
>>> ... the Unix puritan in me abhors hard-linked directories.
>>
>> They are a very, very, very, very bad idea. And completely unnecessary.
>
> Why are they a bad idea?

Consider these two questions:
* How do you detect reference cycles?
* What happens if you don’t?

On Sat, 4 May 2024 14:49:19 -0000 (UTC), Lew Pitcher wrote:

> Note that unix filesystems support a limited, controlled subset of
> hardlinks: the "." and ".." directories found in each directory.

Even those are completely unnecessary. Their interpretation could easily
be hard-coded into the path-interpretation routines in the kernel, instead
of wasting space for these entries in every single directory on a
filesystem.

Muttley@dastardlyhq.com writes:

> On Sat, 04 May 2024 07:50:11 -0300
> Johanne Fairchild <jfairchild@tudado.org> wrote:
>>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>>>
>>>> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
>>>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>>>> <v12on9$ihfm$6@dont-email.me>:
>>>>
>>>>> ... you can't hard link directories.
>>>>
>>>> Sometimes, you can, depending on OS and filesystem:
>>>>
>>>> https://jameshunt.us/writings/linking-dirs-in-macos/
>>>>
>>>> IIRC, Apple's Time Machine uses this capability.
>>>>
>>>> BTW, I'm not mentioning this because I think it's a good idea;
>>>> the Unix puritan in me abhors hard-linked directories.
>>>
>>> They are a very, very, very, very bad idea. And completely unnecessary.
>>
>>Why are they a bad idea? Can you show examples? I can't see it. Thanks!
>
> Probably because there isn't much point (not that IMO there's much point to
> hard links anyway) as when you delete the directory you'll delete all the
> files inside but the now empty directory will still exist wherever its hard link
> is.

Oh, I see. And if we were to fix this by removing the directory as well
in the two or more places it was linked to? Wouldn't it be useful as a
single directory that has two absolute paths? That seems useful to me.

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2024-05-04, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> A hardlink introduces an undetectable cyclicity in the underlying filesystem.
>
> You mean, trouble some cyclicity that is detectable with a lot of
> annoying fuss, that has to be done wherever the filesystem is being
> recursively traversed.
>
>> It must reference an inode within a specific filesystem (and, thus, cannot
>> cross filesystems or mountpoints), and (unlike softlinks) has no other
>> distinguishing feature. This means that you can only determine if a
>> /directory/ hardlink has introduced a cyclical reference by actually
>> traversing the hardlinked directory structures until you return to the
>> starting link.
>
> If you keep the path of inodes you have visited in order to reach a
> certain directory, then you can detect a cycle by checking whether a
> newly visited directory is one of the elements of the path. Since
> paths are reasonably short, you don't need any fancy hash data structure
> for this; a linear scan will work fine in most cases, and so you can
> represent the path as a linked list that is allocated on the stack,
> if working in C.
>
> void recurse(..., visited_node *parent)
> {
> visited_node current = { .up = parent };
> // ...
> }
>
> The cyclic check is simply chasing the parent->up pointers to see if any
> of the visited nodes is the same object as the newly visited one.
>
> The problem is:
>
> 1. Everything that performs traversals of the filesystem now *has* to do
> this, or risk being stuck in a loop. There is a bad habit in the
> Unix programming culture of people rolling their own filesystem
> traversal functions. Some of them would get it wrong, ending up in
> infinite loops.
>
> 2. Even if you have cycle detection, you still have the problem that
> every recursive traversal performed anywhere runs the risk of
> potentially visiting the entire filesystem!
>
> Directory hard links could be restricted to being downward-only. So that
> is to say, if you create a P/C -> D hard link, then X is required to be
> a descendant of P, such as P/X/Y/D.
>
> To check that without race conditions, the kernel would have to lock
> down all operations on that filesystem during the link operation.
> Starting at D, it could navigate the parent .. links until it hits
> the root directory, P, or hits a mount point crossing. If it finds P,
> then it can conclude that the link can be made. (Without TOCtoTOU
> if things are properly locked down.)
>
> Holding a lock over a complex operation like that could open an avenue
> to a DOS attack against the filesystem. Imagine a swarm of threads doing
> directory linking operations, causing that lock to be excessively held.
>
> The descendant restriction would make directory hardlinks inapplicable
> to some people's use cases. (Oh well, they'd have to use symlinks
> for those situations.)

Thanks very much Lew Pitcher and Kaz Kylheku for the lecture. (Ignore
my previous post on the thread asking further. It's all clear now.)

Johanne Fairchild <jfairchild@tudado.org> writes:

> Muttley@dastardlyhq.com writes:
>
>> On Sat, 04 May 2024 07:50:11 -0300
>> Johanne Fairchild <jfairchild@tudado.org> wrote:
>>>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>> On Fri, 3 May 2024 17:38:40 -0000 (UTC), vallor wrote:
>>>>
>>>>> On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07
>>>>> <candycanearter07@candycanearter07.nomail.afraid> wrote in
>>>>> <v12on9$ihfm$6@dont-email.me>:
>>>>>
>>>>>> ... you can't hard link directories.
>>>>>
>>>>> Sometimes, you can, depending on OS and filesystem:
>>>>>
>>>>> https://jameshunt.us/writings/linking-dirs-in-macos/
>>>>>
>>>>> IIRC, Apple's Time Machine uses this capability.
>>>>>
>>>>> BTW, I'm not mentioning this because I think it's a good idea;
>>>>> the Unix puritan in me abhors hard-linked directories.
>>>>
>>>> They are a very, very, very, very bad idea. And completely unnecessary.
>>>
>>>Why are they a bad idea? Can you show examples? I can't see it. Thanks!
>>
>> Probably because there isn't much point (not that IMO there's much point to
>> hard links anyway) as when you delete the directory you'll delete all the
>> files inside but the now empty directory will still exist wherever
>> its hard link
>> is.
>
> Oh, I see. And if we were to fix this by removing the directory as well
> in the two or more places it was linked to? Wouldn't it be useful as a
> single directory that has two absolute paths? That seems useful to me.

Scratch all that. I should've read the entire subthread before asking.