Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 12 Jul 2019 12:02:24 +0200
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali.rohar@gmail.com>
To:     Jan Kara <jack@suse.com>,
        "Steven J. Magnani" <steve.magnani@digidescorp.com>,
        Roald Strauss <mr_lou@dewfall.dk>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: UDF filesystem image with Write-Once UDF Access Type
Message-ID: <20190712100224.s2chparxszlbnill@pali>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hello,

I had discussion with Roald and based on his tests, Linux kernel udf.ko
driver mounts UDF filesystem image with Write-Once UDF Access Type as
normal read/write filesystem.

I think this is a bug as Write-Once Access Type is defined that existing
blocks on filesystem cannot be rewritten. Only new blocks can be
appended after end of device. Basically it means special HW support from
underlying media, e.g. for optical medias packet-writing technique (or
ability to burn new session) and CDROM_LAST_WRITTEN ioctl to locate
"current" end of device.

In my opinion without support for additional layer, kernel should treat
UDF Write-Once Access Type as read-only mount for userspace. And not
classic read/write mount.

If you want to play with Write-Once Access Type, use recent version of
mkudffs and choose --media-type=cdr option, which generates UDF
filesystem suitable for CD-R (Write-Once Access Type with VAT and other
UDF options according to UDF specification).

Also in git master of udftools has mkduffs now new option --read-only
which creates UDF image with Read-Only Access Type.

It seems that udf.ko does not support updating VAT table, so probably it
should treat also filesystem with VAT as read-only too.

-- 
Pali Rohár
pali.rohar@gmail.com