Hello, this is RE the patch 8515b9edf7a0c9dcf1ad218ccc783700db217336 (Upstream commit a9ad01bc759df79b0012f43ee52164391e31cd96) in 4.18.20.
I have an issue with UDF. I used to be able to create a UDF fs in a way that is very similar to this: `# mkudffs --label=.... -m dvd -b 512 /dev/mapper/cryptdev1` I used to proceed mounting it, noticing it got mounted as readonly (because the accesstype of the udf fs is readonly (as decided per -m dvd)), so I remounted it as rw and then was able to fill it with data.[1] Now, this doesn't work anymore since the last time I did that. I figured out it must have to do with the commit mentioned above. All I get now, during a remount-as-rw attempt, is: `cannot remount /dev/mapper/cryptdev1 read-write, is write-protected`. I am not sure if this counts as a regression, because I see the point in not only auto-mounting such filesystems as readonly, but also preventing remounting as rw, however it breaks my use case. However, I noticed the following, too: case A) when having a "readonly udf" on a readwrite device, the filesystem mounts as readonly (old behavior) and also prevents remounting as rw (new behavior) case B) when having a "readwrite udf" on a readonly device, the filesystem mounts as readwrite (!), but the writes end up being invisibly discarded To me, B) sounds just like the kind of issue that the commit, that I mentioned above, promised to fix. In fact, I believe case B to be more severe, because it automatically mounts as rw on a ro device, while the old (pre-patch) behavior of case A correctly mounted as ro and required manual remounting intervention to mount as rw on (potentially) rw - and even then, it's still less of an issue, when the underlying device is writeable. I feel like the correct solution would be to: - disallow mounting as rw if the UDF is ro - disallow mounting as rw if the device is ro - disallow remounting as rw if the device is ro As for the case of remounting as rw if the UDF is ro but the device is rw, I am not sure what the best idea is to deal with this. If this new behavior doesn't count as a regression, is there any way to end up with a UDF filesystem as specced by the command above (-m dvd -b 512, so with it being read-only), but still allow for mounting it as rw if the device supports it? Does udftools offer a way to manipulate the UDF partition descriptor flag in a pre-existing filesystem after it had already been created that I am missing? [1] sanity check: people actually do this: - https://unix.stackexchange.com/a/17613 - https://www.g-loaded.eu/2005/11/10/packet-writing-on-cdrw-and-dvdrw-media/ - https://www.altlinux.org/WritingLargeFilesOnDVD - https://computador.docow.com/como-usair-dvd-rw-udf-tanto-no-windows-quanto-no-linux.html (case 4) -- Kind regards, Kevin Weidemann
