All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org,
	"Steven J. Magnani" <steve.magnani@digidescorp.com>
Subject: Re: udf: Commit b085fbe2ef7fa (udf: Fix crash during mount) broke CD-RW support
Date: Fri, 17 Jan 2020 12:35:37 +0100	[thread overview]
Message-ID: <20200117113537.tvyiz3bictp7p2ki@pali> (raw)
In-Reply-To: <20200117112254.GF17141@quack2.suse.cz>

On Friday 17 January 2020 12:22:54 Jan Kara wrote:
> On Thu 16-01-20 16:46:43, Pali Rohár wrote:
> > On Monday 13 January 2020 12:48:38 Jan Kara wrote:
> > > On Sun 12-01-20 15:47:35, Pali Rohár wrote:
> > > > So I think that UDF 2.60 is clear that for CD-RW medias (formatted in
> > > > normal or MRW mode) should be used Overwritable access type. But all
> > > > mentioned tools were probably written prior to existence of UDF 2.60
> > > > specifications, probably targeting only UDF 1.50 versions at that time.
> > > > 
> > > > I checked that they use Unallocated Space Bitmap (and not Freed Space
> > > > Bitmap), so writing to these filesystems should not be a problem.
> > > > 
> > > > How to handle this situation? UDF 2.01 nor 1.50 does not say anything
> > > > for access type on CD-RW and there are already tools which generates UDF
> > > > 1.50 images which does not matches UDF 2.60 requirements.
> > > > 
> > > > I think that the best would be to relax restrictions added in commit
> > > > b085fbe2ef7fa to allow mounting mounting udf fs with rewritable access
> > > > type in R/W mode if Freed Space Bitmap/Table is not used.
> > > > 
> > > > I'm really not sure if existing udf implementations take CD-RW media
> > > > with overwritable media type. E.g. prehistoric wrudf tool refuse to work
> > > > with optical discs which have overwritable access type. I supports only
> > > > UDF 1.50.
> > > 
> > > Yeah, we should maintain compatibility with older tools where sanely
> > > possible. So I agree with what you propose. Allow writing to
> > > PD_ACCESS_TYPE_REWRITABLE disks if they don't use 'Freed Space
> > > Bitmap/Table'. Will you send a patch or should I do the update?
> > 
> > Could you do it, please?
> 
> Sure, attached.

Looks good, just you have specified wrong MIME enc: charset=iso-8859-1
It should be UTF-8. You can add my Reviewed-by keyword.

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

      parent reply	other threads:[~2020-01-17 11:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-12 14:47 udf: Commit b085fbe2ef7fa (udf: Fix crash during mount) broke CD-RW support Pali Rohár
2020-01-13 11:48 ` Jan Kara
2020-01-16 15:46   ` Pali Rohár
2020-01-17 11:22     ` Jan Kara
2020-01-17 11:31       ` Pali Rohár
2020-01-17 12:27         ` Jan Kara
2020-01-17 11:35       ` Pali Rohár [this message]

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=20200117113537.tvyiz3bictp7p2ki@pali \
    --to=pali.rohar@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=steve.magnani@digidescorp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.