Date: Wed, 12 Feb 2014 21:08:30 -0800 From: Jordan Hubbard <jordan.hubbard@gmail.com> To: Jason Hellenthal <jhellenthal@dataix.net> Cc: freebsd-filesystems@freebsd.org, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Thoughts on Multi-Symlink Concept Message-ID: <A31B3F88-861F-459B-AD67-F146D5514594@mail.turbofuzz.com> In-Reply-To: <CAO2cuEMC==HstC4VkkiFpHyo6LA_xyCjYKvCEECXneVLNnZpZg@mail.gmail.com> References: <CAO2cuEMC==HstC4VkkiFpHyo6LA_xyCjYKvCEECXneVLNnZpZg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 11, 2014, at 9:09 PM, Jason Hellenthal <jhellenthal@dataix.net> =
wrote:
> Instead of: cat /path/to/files*
> ln -sm /path/to/files* ./my_concat_list
> cat ./my_concat_list
>=20
> Or
>=20
> ln -sm /path/to/file1 /path/to/file2 ./my_concat_filters
> pfctl -v -f ./my_concat_filters
Globbing is done in user land (by the shell) - you wouldn=92t want to =
push that down into the kernel, which is either what you=92d have to do =
or you=92d need a user land daemon which did round-trips with the kernel =
to do the translation, which would also need to make sure to get all of =
the process permission stuff right since the user id / gid / $CWD would =
all potentially affect the expansion of the =93symlink=94.
There are other problems. Since =93my_concat_list=94 now expands to =
multiple files, you have to pre-expand its contents before actually =
execing cat(1), and since filenames can have spaces and other magic =
characters (to the shell) in them, you would need to be able to deal =
with escaping all of that. Just like=85 the shell does!
Even worse still, you=92d be essentially creating a new file type with =
very non-file like semantics. Even variant symlinks (/bin -> =
/${ARCH}/bin), which can expand differently depending on the user =
context, have clearly understandable semantics - you know that the =
symlink is going to expand to exactly one file no matter what ARCH is =
set to. How, conversely, would you expect =93cat < my_concat_filters=94 =
or =93dd if=3Dmy_concat_filters of=3D=85=94 to work? You=92ve =
essentially created a construct that can cause truly weird behaviors =
unless you use it in exactly one way and one way only (as a file =
argument list), the user having to explicitly know the difference when =
they consume the symlink. That creates a whole raft of layering =
violations, and is very =93not Unix=94, to be honest.
If you want to get creative along these lines without breaking Unix, I =
think creating some new type of artificial directory that doesn=92t =
actually physically contain files but can flexibly reference a =
collection of files based on some sort of query - that might be =
interesting.
- Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A31B3F88-861F-459B-AD67-F146D5514594>