udflabel: Implement --mark-ro operation

[jtru]

This patch implements a new operation/switch, "--mark-ro", which will set the DOMAIN_FLAGS_SOFT_WRITE_PROTECT flag on both the UDF FSD and LVD (which is what mkudffs does when instructed to create a read-only UDF file system).

Using that, users may "seal" a UDF-formatted mass storage device (e.g., a USB thumb drive) once it has been populated with data.

A resulting UDF 2.01-compliant file system has been verified to mount read-only on both Microsoft Windows 10, as well as GNU/Linux with kernel 6.2.

[pali]

udflabel tool is for setting filesystem label and other label-like identifiers. Really not for changing write-protection of existing filesystem. Such functionality should be in different tool, e.g. udftune.

[jtru]

Thanks for your feedback, @pali - I can see and understand where you are coming from!

If you bear with me for a few paragraphs and hear me out, I would very much like to try changing your mind about it :)

There is no udftune to this date, and implementing it properly would require either a pretty massive amount of code duplicated from what's already inside udflabel, or a rather substantive refactoring effort where current udflabel functionality gets separated into a (shared) library of its own, which will then be used by the (to-be-implemented) udftune executable. I am afraid lack both the the time and the required familiarity with the code base to make that happen.

Furthermore, when coming from other filesystems, there's sometimes two utils in their administrative stack of tools: some executable to tune, another one to label the file system (e. g., tune2fs and e2label for ext[324]). But that is not always the case: For xfs, you set a label with xfs_admin, for instance - which is a more generic tool to maintain that particular fs. And even for e2fs, one can set the volume label via tune2fs -L ..., too, instead of resorting to e2label. So labeling and "tuning"/tweaking file system operations are somewhat closely related to each other - which is only natural, since both actions meddle with file system metadata.

Now, I would argue that labels in xfs and e2fs et al. take on a less important role than what they appear to be in UDF (I am not familiar with OSTA standards - but just comparing the amount of metadata concerning the whole file system - as opposed to an indivudual file contained by it - authorship or a distributor or an implementation that write to the fs, etc. - paints a pretty clear picture for me). Therefore, interacting with the different UDF labels is a much more intricate job than interacting with the single label of, say, an ext4 image. This also shows in the implementation complexity of e2label vs. udflabel.

Therefore, I think it would have been fair to have called the current udflabel udftune (or a smiliar, more generic name) in the first place - since it tweaks a LOT of internal file system structure, depending on the options given during its invocation. Apparently, it can even alter such fundamental UDF file systems attributes as the block size or the start block!

At this point, I think we're getting into a debate over minor semantics - is it really such a problem to have udflabel modify various additional parts of the superblock-like information in a UDF image, even though that information is not strictly label-like data? I would not think so, personally, as long as these other operation(s) are properly documented.

And once there's more functionality that warrants having a dedicated udftune implemented, one might consider splitting the two - or make the resulting object a multi-call binary (akin to busybox), where the identity of the program running is governed by the name it was invoked by, etc. But for the time being, I think just having the option ot make an existing UDF file system read-only, after it has been populated with some data, with udflabel would be the preferable option to have over having a (currently hypothetical) tuneudf some time in the future :)

Thanks very much for having the patience to engage with my train of thought, and also for maintaining udftools! :)

[jtru]

I take it I could not convince you of my point of view then? :-\

[pali]

I have looked at other fs tools specialized for setting fs label and none of them can change write-protection attribute or any other non-label related on existing fs. tune2fs or xfs_admin is not an argument as these tools are general purpose tool, not specific for manipulating labels. Setting some random attribute of the udf fs is really for general-purpose udf fs manipulation tool - e.g. udftune. And no, udflabel is not it, I would not accept extending label tool for unrelated things... with this reasoning somebody else can come and say that want to add ability for e.g. erasing whole disk into udflabel. This is a mess and I'm not interested in hacks.