On 4/19/10, Tom Evans <tevans.uk_at_googlemail.com> wrote: > On Mon, Apr 19, 2010 at 1:48 PM, Paul B Mahol <onemda_at_gmail.com> wrote: >> On 4/17/10, Paul B Mahol <onemda_at_gmail.com> wrote: >>> On Sat, Apr 17, 2010 at 4:31 PM, Tim Kientzle <kientzle_at_freebsd.org> >>> wrote: >>>> Paul B Mahol wrote: >>>>> >>>>> It is apparently not possible to make use of -use-the-force-luke=4gms >>>>> on FreeBSD when appending new session after 4GB. Mounted disk >>>>> afterwards show nothing. >>>>> >>>>> Should we allow it like linux does? >>>> >>>> Are you claiming there is a problem when FreeBSD reads such >>>> images or a problem with creating such images? What >>>> programs are you using? >>> >>> I burn flac files in multiple sessions, each session have separate >>> directory, on DVD+R DL MKM/003 >>> After I used 4gms switch mounted fs shows nothing. (but there is >5GB of >>> data) >>> >>> According to growisofs source BD (bluray) dont need this switch at all >>> ... >>> >>>> This sounds like a pretty unsurprising 32-bit truncation >>>> bug: the filesystem structures in ISO9660 are all sector >>>> numbers so 8TB should be the natural limit (4G sectors >>>> times 2k bytes/sector). >>> >>> I did not tested this on FreeBSD amd64 yet. >> >> Update: Linux shows all sessions and Windows 7 shows only first one. > > > From the source code of groisofs.c: > > * - DVD+R Double Layer support; > * - -use-the-force-luke=4gms to allow ISO9660 directory structures > * to cross 4GB boundary, the option is effective only with DVD+R DL > * and for data to be accessible under Linux isofs a kernel patch is > * required; > > So I'm guessing it does something non standard, particularly if > windows also refuses to see the data. That is pretty old, from 2.4 era, it was added after it was found that isofs had bug. Windows at least "try" to show something - only one session, but fourth and not second session crossed 4GB limit. The source also claims that in BD case there is no need for _force_ switch at all.Received on Mon Apr 19 2010 - 13:18:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC