From: "Pali Rohár" <pali.rohar@gmail.com>
To: Michael Sabolish <sabolish@me.com>
Cc: Jan Kara <jack@suse.cz>, Kevin Weidemann <kwe-lnx@postn.eu>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: udf: Prevent write-unsupported filesystem to be remounted read-write
Date: Tue, 15 Jan 2019 09:31:11 +0100 [thread overview]
Message-ID: <20190115083111.qq2mt2p2kn4opwx7@pali> (raw)
Message-ID: <20190115083111.KPr8kHvsFYepg68CynwhitniBTI7GPG7rJFYGnwhsOg@z> (raw)
In-Reply-To: <E11914DA-D254-4198-A152-F9D6E61514BE@me.com>
On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> I can try and make a pull-request for udftune, and I can just copy the API for tune2fs. It would work something like:
>
> udftune -O read-only device (to set read-only access type)
>
> or:
>
> udftune -O ^read-only device (to clear read-only access type (aka set rw))
This API is ambiguous. What does it mean for ^read-only? In UDF you have
following access types: overwritable, rewritable, writeonce, readonly,
pseudo-overwritable, unknown.
So you would need to know to which R/W access type to switch
(overwritable, rewritable, writeonce or pseudo-overwritable).
With information of media type, you could be able to guess correct
access type. But for UDF images stored in VFS there is no media
information. Also you can have uncommon setup, e.g. usage of CD-R
writeonce setup on CD-R/W disc. So "autodetection" of media type would
not work always correctly.
So I think that it would be better to have following API:
udftune --access-type=<new_access_type>
or
udftune --change-access-type=<new_access_type>
I understand that you would like to have similar API as tune2fs, but UDF
settings are too different from ext*.
--
Pali Rohár
pali.rohar@gmail.com
next prev parent reply other threads:[~2019-01-15 8:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <124cc6ea-ca79-20f2-651e-c2f909729ac0@gmx.de>
[not found] ` <8cf39b7c-505b-91e6-849d-e66ba980042f@postn.eu>
2019-01-14 10:30 ` udf: Prevent write-unsupported filesystem to be remounted read-write Jan Kara
2019-01-14 10:30 ` Jan Kara
2019-01-14 12:00 ` Pali Rohár
2019-01-14 12:00 ` Pali Rohár
2019-01-14 12:30 ` Jan Kara
2019-01-14 12:30 ` Jan Kara
2019-01-15 3:07 ` Michael Sabolish
2019-01-15 3:07 ` Michael Sabolish
2019-01-15 8:31 ` Pali Rohár [this message]
2019-01-15 8:31 ` Pali Rohár
2019-01-15 8:41 ` Jan Kara
2019-01-15 8:41 ` Jan Kara
2019-01-15 8:48 ` Pali Rohár
2019-01-15 8:48 ` Pali Rohár
2019-01-15 9:45 ` Jan Kara
2019-01-15 9:45 ` Jan Kara
2019-01-15 10:50 ` Pali Rohár
2019-01-15 10:50 ` Pali Rohár
2019-01-15 11:15 ` Jan Kara
2019-01-15 11:15 ` Jan Kara
2019-01-14 15:12 ` Pali Rohár
2019-01-14 15:12 ` Pali Rohár
2019-01-14 16:26 ` Kevin Weidemann
2019-01-14 16:26 ` Kevin Weidemann
2019-01-22 13:22 ` Jan Kara
2019-01-23 20:29 ` Kevin Weidemann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190115083111.qq2mt2p2kn4opwx7@pali \
--to=pali.rohar@gmail.com \
--cc=jack@suse.cz \
--cc=kwe-lnx@postn.eu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sabolish@me.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).