Date: Mon, 7 Nov 2011 15:19:56 +0100 From: =?iso-8859-1?Q?G=E1bor_S.?= <otnaccess@hotmail.com> To: <linux-fsdevel@vger.kernel.org>, <freebsd-fs@freebsd.org> Subject: Symbolic link with absolute target path in UDF - not working properly? Message-ID: <SNT126-DS16790C97DEE1A7233F9AC4BED90@phx.gbl>
next in thread | raw e-mail | index | archive | help
Hi everybody, Preamble: the presumed misbehavior is exhibited by both operating systems - although in different forms; that's why I'm crossposting to the file system mailing list of both operating systems now. 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. - 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... 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... Thanks, Gabor Suranyi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SNT126-DS16790C97DEE1A7233F9AC4BED90>