Date: Wed, 1 Jun 2022 16:56:04 +0200 From: Polytropon <freebsd@edvax.de> To: Tomek CEDRO <tomek@cedro.info> Cc: FreeBSD Questions Mailing List <freebsd-questions@FreeBSD.org> Subject: Re: UDF mount failed: Unsupported partition map: *UDF Virtual Partition Message-ID: <20220601165604.0096531c.freebsd@edvax.de> In-Reply-To: <CAFYkXjm_K2Tp3JGv5iNBSjhuKvw2MzELqWZU7LY6TwC==JrEQw@mail.gmail.com> References: <CAFYkXjm_K2Tp3JGv5iNBSjhuKvw2MzELqWZU7LY6TwC==JrEQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 31 May 2022 21:48:28 +0200, Tomek CEDRO wrote: > Today I had to read DVD disk with medical data (DICOM + Viewer). It > was burned probably by a MRI scanner operator station directly in a > way that mount_udf (nor mount_cd9660) could not mount it. macOS also > could not open the disk. Windoze 10 opened it with no problem. The reason is simple: FreeBSD's mount_udf does not support all of the existing UDF versions and variations, only a kind of lower "common ground". > I was able to DD disk with no problem for investigation. Disk does not > seem to have valid ISO signature (hybrid ISO+UDF). Is there any chance > that this is the ISO+UDF disk but FreeBSD does not support modern UDF > versions? Maybe some sort of raw UDF disk? You can use the udfclient program from the udfclient package. Then do as follows: % udfclient /dev/cd0 cd "XXXXXXXX UDF Volume Set:UDF Volume:XX XXX XXXX:UDF Volume Set" cd "XXXX.XX - XXXXXXXXXXXXXX" get "XXXXXXXXXXXXXXXXXXXXX_I.pdf" get "XXXXXXXXXXXXXXXXXXXXX_II.pdf" get "XXXXXXXXXXXXXXXXXXXXX_III.pdf" get "XXXXXXXXXXXXXXXXXXXXX_IV.pdf" quit % Don't try "man udfclient", there is none. ;-) However, you can use the "help" command at the UDF> prompt. There are similarities to FTP, so it's no big deal. You can use the udfdump program to examine the structure on the disc, so you can easily find out what is actually stored, and how, under which names. In verbose mode, you get something like a directory listing, so you can examine the structure before you "enter" the device or image file. :-) I found OpenBSD-related documentation which states (but sorry, I don't know where I found this, I just have a text file with some notes): The UDF root directory is named with colon separated strings. ":::" The udfclient requires a 'cd' into this root directory before you can read or write files and directories. Spaces will require quoting the string between " " character So the first thing you need is to change into that directory as seen in the example above. Everything else can easily be concluded. Remember to use proper quoting for spaces. More information here: http://www.13thmonkey.org/udfclient/ > I am wondering is this a problem of particular MRI device or there is > some sort of new way of optical disk writing that FreeBSD does not yet > support? No, it is a problem caused by "Windows". As you could see, the disk has been intendedly created to be used with "Windows", and it surely comes from a system that runs "Windows", and nowadays "Windows" defaults to UDF when creating data discs on DVD media, instead of the commonly used ISO-8660 DVD format. There are some good reasons to do so, but as you experienced, it will limit the possibilities to actually _use_ the disc, or make it more and more complicated than it needs to be. This is not isolated to MRI et al.; I once got material for further investigation created by a lawyer, and it also was in a format that FreeBSD could not read with regular means. With udfdump (mentioned above), you get results like Primary volume `UDF Volume` (part 1/1) created by implementator `*Microsoft Windows' So what I got was a learning opportunity, combined with a 4.7 GB DVD wasted for 15 MB of data. But hey, who cares... :-) This works so flawlessly under "Windows" because they seem to have included the required libraries to include them in their software, and you pay for them being there. However, as described above, there was a solution that worked, so I didn't have to buy a new PC and license a "Windows". ;-) As UDF seems to be the established successor of ISO-9660 now, it would be nice to either have that included in FreeBSD's OS (base system) or at least at FUSE level, so a proper mount command can be constructed again... well, seems that OpenBSD is ahead again... :-) Good luck! PS. ImageMagick can convert DICOM files, and wine usually can run the proprietary DICOM file viewers just fine. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220601165604.0096531c.freebsd>