> Lars Tunkrans <[EMAIL PROTECTED]> wrote: > > > Dennis , I agree with you that SNV70 is not > mounting a Vista UDFS dvd correctly > > > I did a clean Install of Snv_70 on a new disc ( a > 10.000 rpm disc which contributes > > nicely to the speed of the system btw ) > > > > The automount by HAL and rmmount did not mount > the UDF filesystem > > There was a similar bug reported in May from Casper > Dik (6562403). > > Unfortunately Casper did never send the information I > asked for, so the problem > could not be investigated. > > > > > All it did was mounting a HSFS where a little > text file " readme.txt" with > > the following message appeared. > > > > "This disc contains a "UDF" file system and > requires an operating system > > > > that supports the ISO-13346 "UDF" file system > specification." > > If your problem is that the medium you mounted is > incosistent, then you would > complain at the manufacturer/publisher. > > The problem with CD/DVD/.... media is that this media > usually now contain 3 > filesystems in 4 flavors: > > - ISO-9660 > - ISO-9660 Rock Ridge extensions > > - Joliet > > - UDF > > If you ask a utility (like e.g. fstyp) whether a > specific filesystem type is > available, you will typically get positive replies > for all filesystems! > > Media handling on Solaris is unfortunately based on > asking this way and the > first ask that results in a positive will be turned > into a mount action. > > **** I just found that we did forget to enhance > /usr/lib/fs/hsfs/fstyp to know > about Joliet when Joliet support was added a year > ago.... > > In any case, we will get into trouble! > > - The DVD manufacturers believe that there is a > standard that requires > UDF on a DVD medium. > > - There is no such "requirement" for other media > types.... > > - Many people believe that UDF is a better choice > than ISO-9660, but this > is not correct from my experiences: > > - UDF limits single files to a max of ~ 200 GB > > - ISO-9660 limits single files to 8 TB > > This all will not create real problems in case that > you manually mount the > medium, but it will cause trouble if you auto-mount > with any possible rule-set. > > > > > Only after I did the below command could I see > the files on the UDF disc. > > > > # mount -F udfs -o ro /dev/dsk/c1t0d0s2 /mnt > > > > and even then fstyp(1M) reports that its a HSFS > file system > > # fstyp -v /dev/dsk/c1t0d0s2 | more > > hsfs > > CD-ROM is in ISO 9660 format > > System id: > > Volume id: LRMCXFRE_EN_DVD > > Volume set id: LRMCXFRE_EN_DVD > > Publisher id: MICROSOFT CORPORATION > > Data preparer id: MICROSOFT CORPORATION, ONE > MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080 > > Application id: CDIMAGE 2.52 (03/09/2004 TM) > > Copyright File id: > > Abstract File id: > > Bibliographic File id: > > Volume set size is 1 > > Volume set sequence number is 1 > > Logical block size is 2048 > > Volume size is 1853755 > > ------- > > Media format detection is obviously not working > with UDF. > lease repeat the text using "isoinfo -d". If isoinfo > _also_ reports a Volume > size of 33.6 GB, then this is a medium that has been > created by a > (intentionally???) buggy application. > > Jörg
Ok, a question and a comment: question: can hald (or whatever it uses) distinguish between hybrid filesystems (sharing some or all files and file data blocks but having different metadata) and distinct filesystems? Seems to me that all _distinct_ filesystems should be mounted, but ideally just the _preferred_ one of the hybrid filesystems should be mounted. comment: The problem is how to determine "preferred"; that arguably relates to the target audience(s) and system(s) (and how they would handle the media) more than anything else, so I doubt there's a simple answer at this time. For some hybrids, there may be a "preferred" filesystem type; but for many, different types might be appropriate to different OSs (i.e. a RockRidge+Joliet+HFS might be appropriate for RockRidge on Unix/Linux, Joliet on Windows, and HFS on MacOS), although there might be exceptions. It would at least be nice if Linux and Solaris (and maybe some of the *BSDs) agreed on how to handle such situations more or less consistently. If a convention was developed for a hints file name and contents that described which fs to prefer under what conditions (and was visible under a consistent name in all the variants of a hybrid), that would allow for media that contained it, some clear indication of the media author's intent. But I don't know that anything like that exists, and it wouldn't help existing media or platforms not supporting it. As for writable media: first, for _any_ hybrid filesystem, I think I'd favor mounting it read-only, even if one only mounts udfs, and even if the media is writable. That's because I think that determining how (and if) it was possible to write to the filesystem without invalidating the other hybrids might get unreasonably complicated; and I think it's better to default to doing something safe rather than something maximally enablling. If someone wants to do something trickier, they can always stop hald and mount by hand. Although IMO it would be nice if one could either communicate to hald that it should give up interest in/reclaim interest in a specific device, or that until the next media change on a particular device, it should alter its default behavior. That would allow either (simpler) taking manual control of a single device without stopping hald, or (trickier) having it undo whatever it did for a particular media and then redo it with altered behavior as specified. With some work, that could be reasonably safely and easily controlled by the end user (as long as they couldn't override nodev/nosuid). I don't think mounting all variants of a hybrid is a good long-term answer (it's not what the intended audience(s) of the media would likely do, rather the media would have been designed to produce known results on the OS(s) for which it was intended). But a good long-term answer (esp. with broader community support so it's across Linux and Solaris) might take awhile. So mounting all variants, if done, should probably be documented as a stopgap measure that might change in a future update. IMO, of course... This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
