Hi, On Sun 04-12-11 20:43:31, Gábor S. wrote: > since it did not make through to the linux-fsdevel list for some unknown > 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 :) > I recently wanted to archive a bunch of data from my (well, Linux) box > faithfully, that is keeping not only the hard links but also the symbolic > 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 creating 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 googling led > me to mkisofs (from cdrtools 3.01) and I created an image containing both > ISO9660 and UDF file systems with that. > > 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 symbolic > links with absolute target path were not working as I expected. For the > rest, let us assume that the image contains a file called mounttab which was > linking to /etc/mounttab on the source from which the image was created. > > - 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 mounttab > actually points to /etcmounttab which is obviously erroneous. > > What I experienced made me also suspicious that mkisofs might be at fault. > So I set up another Unix-like OS and mounted the image... > > - On Oracle Solaris (Oracle Solaris 11 Express 2010.11, LiveCD): all the > symbolic links including the ones with absolute target path work as > expected. > > To investigate what is going on I had a look into the UDF specification > (ECMA 167) and the source code of the UDF writer of mkisofs and the UDF file > system drivers of the above mentioned operating systems. The result is... > > - According to the UDF specification: the target of the symbolic links is > broken into path components (/, etc, mounttab in the example) and that > target is basically represented as a sequence of those, where the root > 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 as > component type 2. OK. While the meaning of component type 1 is clear to me in the standard (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 agreed between the creator and consumer of the disk), I have trouble parsing the 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 member." 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 the 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 cannot be easily expressed in terms of ., .., or /. It is even harder considering that root of the filesystem need to even be reachable in the current name space (because of bind mounts and such stuff). Also readlink(2) implementation is problematic since root of the current filesystem is not 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?view=mar > kup) processes component type 2 (and bails out finding component type 1 > actually). Upon processing the flag root is set to true which is meant (I > think) to suppress appending a slash after the component name to avoid > 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 the > second path component only. > - OpenSolaris (see > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/ > udfs/udf_vnops.c) processes component type 2 as / itself and component type > 1 as the root directory of the medium itself. (And in the UDF file system > creator part: the root directory is actually represented as component type 2 > just as mkisofs does.) This is too my interpretation of the standard... 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 difficult to > explain for sure... Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
