From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: FW: Symbolic link with absolute target path in UDF - not working properly? Date: Wed, 7 Dec 2011 19:06:37 +0100 Message-ID: <20111207180637.GM4622@quack.suse.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: =?iso-8859-1?Q?G=E1bor_S=2E?= Return-path: Received: from cantor2.suse.de ([195.135.220.15]:44325 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756938Ab1LGSGj (ORCPT ); Wed, 7 Dec 2011 13:06:39 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, On Sun 04-12-11 20:43:31, G=E1bor S. wrote: > since it did not make through to the linux-fsdevel list for some unkn= own > reason, I'm trying your address - according to the Maintainers file, = you are > maintaining the UDF driver for Linux... Yes, you chose the right address :) =20 > I recently wanted to archive a bunch of data from my (well, Linux) bo= x > faithfully, that is keeping not only the hard links but also the symb= olic > links present. I wanted to directly represent the files on a DVD, so = I opted > for creating a disc (image actually) in UDF format instead of creatin= g a tgz > archive or similar and burn that to a DVD. The next step was to find = an > application to build the UDF image with symbolic links. A short googl= ing led > me to mkisofs (from cdrtools 3.01) and I created an image containing = both > ISO9660 and UDF file systems with that. >=20 > Then I mounted the image (because I had the premonition that symbolic= links > in UDF are less commonly used) - and got pretty surprised since the s= ymbolic > links with absolute target path were not working as I expected. For t= he > rest, let us assume that the image contains a file called mounttab wh= ich was > linking to /etc/mounttab on the source from which the image was creat= ed. >=20 > - On Linux (kernel 3.0.4): the slash (/) at the beginning is omitted.= So > mounttab actually points to etc/mounttab which is not absolute. > - On FreeBSD (GhostBSD 2.5 BETA 3): the names of the path components = are > simply pasted together without any directory separator (/). So mountt= ab > actually points to /etcmounttab which is obviously erroneous. >=20 > What I experienced made me also suspicious that mkisofs might be at f= ault. > So I set up another Unix-like OS and mounted the image... >=20 > - On Oracle Solaris (Oracle Solaris 11 Express 2010.11, LiveCD): all = the > symbolic links including the ones with absolute target path work as > expected. >=20 > To investigate what is going on I had a look into the UDF specificati= on > (ECMA 167) and the source code of the UDF writer of mkisofs and the U= DF file > system drivers of the above mentioned operating systems. The result i= s... >=20 > - According to the UDF specification: the target of the symbolic link= s is > broken into path components (/, etc, mounttab in the example) and tha= t > target is basically represented as a sequence of those, where the roo= t > directory is represented in a special manner, as so called component = type 1 > or 2. (While standard path components such as etc and mounttab have a= type > of 5.) > - mkisofs represents the root directory of the absolute target path a= s > component type 2. OK. While the meaning of component type 1 is clear to me in the stand= ard (i.e. if length of the component is 0, component points to the root of = UDF filesystem, if the length is > 0, the component points to a place as ag= reed between the creator and consumer of the disk), I have trouble parsing t= he meaning of component type 2. In particular the wording is: "The component specifies the root directory of the directory hierarchy = of which the predecessor of the first component in the pathname is a membe= r." Some light to this sheds 2/8.7 which says among other things "The predecessor of the initial component shall be the directory in which th= e pathname is described." - i.e. if the symlink exists in foo/bar/ on the filesystem then "the predecessor of the first component in the pathname= " simply refers to foo/bar/ if I understand it right. In this light, type= 2 is really meant to point to the root of the filesystem and 2/8.7.1 seems to confirm this by stating that a resolved pathname should begin = with a component of type 2. So in this light, type 1 might be intented to point to the root of the whole filesystem hierarchy while type 2 points just to the root of the current filesystem. That being said it is kind of hard to implement symlink pointing to the root of the current filesystem - such thing can= not be easily expressed in terms of ., .., or /. It is even harder consider= ing that root of the filesystem need to even be reachable in the current na= me space (because of bind mounts and such stuff). Also readlink(2) implementation is problematic since root of the current filesystem is n= ot expressible by a simple path. I'll try to ask for some suggestions in the linux-fsdevel list. > - Linux expects the root directory of the absolute target path be > represented as component type 1. Component type 2 is simply ignored. > - FreeBSD (see > http://svnweb.freebsd.org/base/release/8.2.0/sys/fs/udf/udf_vnops.c?v= iew=3Dmar > kup) processes component type 2 (and bails out finding component type= 1 > actually). Upon processing the flag root is set to true which is mean= t (I > think) to suppress appending a slash after the component name to avoi= d > double slashes at the beginning of an absolute target path (which is = used to > separate the component names otherwise). However, the flag root does = not get > cleared because the corresponding code part gets executed only from t= he > second path component only. > - OpenSolaris (see > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/com= mon/fs/ > udfs/udf_vnops.c) processes component type 2 as / itself and componen= t type > 1 as the root directory of the medium itself. (And in the UDF file sy= stem > creator part: the root directory is actually represented as component= type 2 > just as mkisofs does.) This is too my interpretation of the standard.= =2E. Hum, as I wrote above I'd understand the standard just the other way around - i.e. type 2 is root of the medium, type 1 is '/'. > What do you think? Are Solaris and mkisofs right? Or Linux? FreeBSD's > implementation of the symbolic links on the UDF file system is diffic= ult to > explain for sure... Honza --=20 Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html