Symbolic link with absolute target path in UDF - not working properly?

[Gábor S.]

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