I'm trying to create an ISO which contains a symlink (aka soft link). mkisofs is the tool of choice, and according to its readme should be up to the task (since v1).

The destination of the link is not within the filesystem I'm including on the ISO, and I don't want to include the actual files. I just want the symlink to be copied, and to still point to the same path/location.

If I've understood correctly, enabling rockridge extensions should allow this (using either -r or -R).
As I don't want the actual destination copied, the -f option is not set.
Enabling Joliet is sensible in any case just in case of long filenames.

So this should do it:

mkisofs -J -r -o mybroken.iso foo:bar/

but all I get instead of a symlink is a zero byte file of the same name with no functionality. :(

Any ideas?
Have I misunderstood the what/how/why of rockridge extensions supporting symlinks, or am I just missing something?

Thanks.

You're out of luck - cdrive (the MorphOS' CD filesystem) does not handle the RockRidge softlinks.

Quote:

Thanks Jacadcaps,

That's a shame, I've run up against a few brick walls with my current challenge, this was hopefully going to be the simple solution.

Basically, I'm playing around trying to create a semi-ISO based installation, where sys:prefs is abstracted out to a writeable filesystem (ISO recreated without it) and the rest of sys remains on the ISO.

This is entirely not supported, I know. I am a bad man! :)

The simplest approach would be to add in an Assign sys: foo:bar ADD near the start of startup-sequence.
This works fine, but some graphical resources are accessed (prefs/gfx, etc) prior to startup-sequence executing, so my "assign sys: foo/bar ADD" hack arrives a little too late.
It all works ok, but visually looks square, grey, monochrome... it all looks a bit like AROS. :D

Next approach was to try creating a symlink to the writeable prefs folder and recreate the ISO. This would require symlink support in at boot time though, so it doesn't work.

Most promisingly, I've also tried using the PC (preload command) boot option which should work fine, but the use of "" around the preload command is interpreted as surrounding a string by Openfirmware/Forth (when used in a boot menu).

eg : bootmorphos37 " Booting MorphOS 3,7..." .printf 100 ms load-base release-load-area " &device;:&partition;,\bootmonster\3.7\boot.img bi DH2:ISO/morphos-3.7.iso PC="sys:morphos/c/assign sys: foo:bar ADD" ramdebug" $boot ;

I think I need a (Forth) escape character, but I've no idea what that is as yet (Forth is not a nice keyword for googling) - if you have any ideas do let me know.

[ Edited by boot_wb 28.05.2015 - 08:29 ]

Do you need whole SYS:Prefs/ to writable media, or wouldn't just assigning ENVARC: be enough for the most cases?

Quote:

I see no problem
Code:
i.e. a continuing quotation mark and an ASCII in hex in parentheses

Quote:

Desktop icons, panels.. most Ambient stuff iirc - just experimenting to see how close I can get to having every compatible MorphOS version available on one partition (already done) and usable (nearly there).

@Polluks

Thanks, will give that a go :)

Quote:

Now done. envarc assign had me fooled for a while, as I thought it was set up in startup-sequence.

A few bugs to iron out (mainly Odyssey caching fonts on every launch, despite being launched from a writeable location), but nothing that a bit of work with Snoopium won't solve.

I'm now down to the default three partitions (Boot, System, and Work - DH1, DH2 and DH6 respectively... a hangover from previous partitions which have been removed) booting MorphOS 3.1 - 3.8 with a working (saveable) Ambient desktop in each one.
The ISO-based installs are noticeably a little bit slower - presumably the hit is due to using CDFS to access a virtual disk image, rather than SFS on a physical disk.

The boot menu command line became

: bootmorphos38 " Booting MorphOS 3.8..." .printf 100 ms load-base release-load-area " &device;:&partition;,\bootmonster\3.8\boot.img bi DH6:ISO/3.8/morphos-3.8.iso PC="(22)execute DH6:ISO/3.8/user-startup-hack"(22) ramdebug" $boot ;

my user-startup-hack script contains:

assign sys: work:ISO/3.8
assign sys: cdrom: ADD
assign envarc: sys:prefs/env-archive

Reassigning sys: like that might behave unpredictably, as I've no idea if the preload command is executed asynchronously to other processes, but it seems to work ok so far and as expected seemed to result in a lot less lag (since read/writes to/from sys:prefs don't have to access the ISO most of the time).

It may be a useful way of keeping multiple installs for testing without having 27 different partitions, with a bit more flexibiliy than just booting the ISO and quitting bienvenue. :)