From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 13 05:08:34 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 910D3C59 for ; Thu, 13 Feb 2014 05:08:34 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 604C017FE for ; Thu, 13 Feb 2014 05:08:34 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id kx10so10223306pab.7 for ; Wed, 12 Feb 2014 21:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/yTULM99MKn6cPVba8StvlEWlZf5g4xfAEnVFOAE9vQ=; b=ASvhIkndNsVwYzo6rquWaDj/z5y7tiBFGBw3ifbQ5FRk4x0dBNAc3vxZrA/ztFPcap V6DT1AXGlt3+GVvDPMTZxqeZ2HOsvY9e1y9Aehnrcw+AhqunUl0zusKdAxqZ5lcHx1K+ jEWjmpDpuk2m2PZ04XLyCo9ow4ViQxF6WN3/krTb9rjK97SheK3t7/WgTY5XCxonoktt q/8SvS8vY8QcsEnJiNTZTkRHH3Cb26yDMWHTwGtbbReXzMj/QeIGgfEvyIrjZOLrFCtp C/jRAUo0YGcmKcuKJxtkrqMJ7ltZv4G0C7/yLxOHTKb0YTIg+RLMgk7KywlN7KL23536 CvUQ== X-Received: by 10.66.163.2 with SMTP id ye2mr43396492pab.110.1392268113860; Wed, 12 Feb 2014 21:08:33 -0800 (PST) Received: from [10.20.30.117] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id qh2sm5182846pab.13.2014.02.12.21.08.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 21:08:32 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Thoughts on Multi-Symlink Concept From: Jordan Hubbard In-Reply-To: Date: Wed, 12 Feb 2014 21:08:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jason Hellenthal X-Mailer: Apple Mail (2.1827) Cc: freebsd-filesystems@freebsd.org, "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 05:08:34 -0000 On Feb 11, 2014, at 9:09 PM, Jason Hellenthal = 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