cdrkit vs. dvd+rw-tools and the dvd iso 4gb max filesize problem
in [FreeBSD]
|
Prev: 9,000 ZFS mount points
Next: No internet access
From: Indi on 16 Jan 2010 22:27 On 2010-01-16, CeDeROM <tomek.cedro(a)gmail.com> wrote: > Hello Indi! > > On 16 Sty, 21:37, Indi <i...(a)satcidananda.16x108.merseine.nu> wrote: >> Tomek, I added a loophole to my scorefile to unblock you after seeing your >> posts via someone else's replies (as I've done with five other posters here). > > What does that mean? I do post via google... > Google Groups is a huge source of spam and trolling for a lot of usenet groups, so awhile back I made the decision to block all posts coming from GG. If someone posts with something worthwhile, someone else will reply and I'll see that and then can make a loophole in my scorefile to allow that GG poster through. Lots of people do the same, you might want to look into getting a proper news provider and use a newsreader. Some usenet providers are free (motzarella is one), the one I use (individual.net) costs only 10 euros (about $14 U.S.) per year. Check out http://twovoyagers.com/improve-usenet.org/ for more info if you like. > > Well about the filesystems - I have checked the filesystem generated > with: > > 1. mkisofs -iso-level 3 > -it contains malformed and doubled trucated files > -it does not mount as UDF (mount_udf: /dev/cd1: Invalid argument) > > 2. mkisofs -iso-level 3 -udf > -it contains malformed files as above when mounted as ISO9660 > -it does mount as UDF (mount -t udf) and then contains one file, the > checksum is correct (5dea4dc0d18def1978235bb4c4201569, filesize > 4686887250) > > 3. genisoimage -iso-level 3 -allow-limited-size > -without explicte giving the "-udf" parameter it can be mounted as UDF > filesystem and chekcsum of the large file seems to be correct > (5dea4dc0d18def1978235bb4c4201569, filesize 4686887250) > > It looks that the only working combination of the new mkisofs is the "- > udf -iso-level 3" and then disk must be mounted as UDF, otherwise > large files will be doubled and truncated. > > Can anyone confirm that? > So are you saying that using the -udf option with --iso-level 3 works fine, so long as it's mounted udf? If so, that's very good to know. > ps/2: Indi - you can use DVD+RW for experiments - this will save your > resources and the environment :-) > ISTR concerns years back about DVD+-RW being less reliable. Maybe they're better now? Cheers, -- indi Google Groupers and X-posters are filtered. If you're not a troll or a spammer then you might want to stop posting like one.
From: Michel Talon on 17 Jan 2010 09:29 Joerg Schilling <js(a)cs.tu-berlin.de> wrote: > > The first page from the man page as well as the -UDF description > should be obvious enough, isn't it? > Joerg, cdrecord is a wonderful program, but, whatever you may think, and for whatever reasons it is this way, the man page is a *catastrophe*, and i try to be polite. You cannot expect people will read pages and pages of stuff which don't make *any sense* except for experts, and users are not experts. Of course you are not alone with man pages of this sort, i have a headache each time i intend to use mplayer or mencoder. It is because of such unreadable documentation (this is more or less the same of many Unix man pages) that people use front ends like brasero or k3b, or run inferior operating systems. -- Michel TALON
From: CeDeROM on 17 Jan 2010 10:51 Hello Joerg! On 17 Sty, 13:06, j...(a)cs.tu-berlin.de (Joerg Schilling) wrote: > It seems that you did not read the beginning of the man page. It is > _very_ obvious about the fact that it creates hybrid filesystems. Correct, at that point I have used the man page from the stable (outdated) release. In a new manual page everything is clearly explained abut the hybrids - however it might not be obvious at first glance and the old manual. People that want to burn a disk don't have to be experts in this area, just users, so they will probably open manual, search for interesting option, and apply this option. The manual should be written in a manner that allows easy search and apply the information. The information should be also self explanatory and it is possible in English, as the IC manufacturers ofthen do in their technical documents... On the other hand I wouldn't ask you so many questions if I could write my own software for my own optical writer. > Also the UDF description: > > -UDF Include UDF support in the generated filesystem image. > UDF support is currently in alpha status and for this > reason, it is not possible to create UDF only images. > > BTW: I need to remove the remark about the alpha status ;-) > The support is mature since Spring 2007. The current release is still aplha. If the UDF support is not in alpha anymore - is it possible to create UDF only images already? > The problem with programs like brasero that are developed on Linux is that > these programs are stuck to the features from 5 years ago because too > many Linux people believed that wodim is a successor of cdrecord although > wodim is just a dead end from an outdated version. I think that making releases periodicaly can help in this situation - people get confused like I did - with no additional details it is very easy to think that way, especially when the other solution is working. When there is no stable release in a project it might be considered more "dead" than active project that make often releases with a bux fixes. You can always keep your software alpha state because always there will be something new to add. In this situation people search for a working solution and if they find cdrkit that is confirmed by some other people, they will use it and wait or even support it for the next, better, releases. The other thing is that as you said, programs like brasero are stuck to the features from 5 years ago, because there was no STABLE release of cdrtools since then. This is perfectly clear to me. > Why didn't you look at -UDF? > > The first page from the man page as well as the -UDF description should be obvious enough, isn't it? Yes, in the devel package (the alpha release) it is, but the default for us is the outdated one, because it is the stable release, so it is not that obvious :-( > >What does it mean "rationalized" in case of a filesystem? > > Did you read the -r description? Yes I have read that section, but explictily there is no information that this means "rationalized" - please take a look - there is only one search result for "rationalized" and one for "Rationalized", and none of them resides in the "-r" description. > A stable release is a release where at the time of publishing no known > bug exists. While there has not been a single stable "cdrkit" release as > long as it exists, there have been more than 60 stable cdrtools > releases since 2005. > (...) > What "standard" are you talking about? Are you talking about otehr > software that published bad beta releases? > (...) > As any of the current releases is better than all previous releases, > I don't see any reason to put pressure on a stable (== dead) release > to come out soon. This situation is sick. Joerg, plese don't get me wrong but I start to understand the creators of the cdrkit utiliy. If you say that there have been more than 60 stable releases of "cdrtools" since 2005, why the version is still 2.01 since September 2004??? What is more - you convince us that there is no pressure on a stable release :-( :-( > >Woops --- no problem until I extract them! > >It appeared I had made and burned an iso with an 8GB tar file in it, > >upon closer inspection only 4GB actually went to disk but it went twice. > >I got 2 duplicate (not split) 4GB archives on the disk. > > If this is true, then the FreeBSD kernel does not support large files. > > The "trick" with the ISO-9660 standard is that it defines that lage files > have to be written as multi-extent files that have one directory entry per > extent. The filesystem driver in the kernel needs to hide this fact from the > users. > (..) > Well as mentioned later, the current mkisofs implements support for > large files while the current FreeBSD kernel does not seem to support > large files. It seems that the current FreeBSD kernel needs to be > called "alpha" for this reason ;-) If you think that FreeBSD kernel needs to be called "alpha" for any reason, you are invited to make improvements -it is still open under very nice license for modifications. > I am sure that if FreeBSD did deliver recent cdrtools versions by default, > the missing features in the kernel would have been detected much earlier. Joerg this is way to far and wrong conclusion. If you read the earlier posts you could find that the filesystem created with "-udf -iso-level 3" works fine if mounted as the UDF filesystem, and this is probably because if the filesystem is an ISO carrying some additional UDF data, then it could be read as ISO and UDF, where only the UDF filesystem is correct - that is why "-udf" switch was used to create the filesystem. This is the logical standard that I was talking about - this is clear to me, I like it. Now I can understand why the cdrkit was born... you write more about the errors of the concurent software instead of improving yours and listening for a feedback. If you read our messages carefully you could notice that we do like cdrtools and we try to help improve it as we can by our feedback. You did not ask for any other support than reading the manual. For me this is enough, I got tired by the subject, I won't ask you for anything if that's what you want. Please just notice that this attitude brings nothing good to the *nix world. Good luck with your software. Anyone knows any burning solution for unix other than cdrtools? This surely can be a commercial one, I just want it to work. Regards, Tomek
From: Indi on 17 Jan 2010 10:52 On 2010-01-17, Joerg Schilling <js(a)cs.tu-berlin.de> wrote: > In article <7recpnF5o0U1(a)mid.individual.net>, Indi <indi(a)127.0.0.1> wrote: >> >>Woops --- no problem until I extract them! >>It appeared I had made and burned an iso with an 8GB tar file in it, >>upon closer inspection only 4GB actually went to disk but it went twice. >>I got 2 duplicate (not split) 4GB archives on the disk. > > If this is true, then the FreeBSD kernel does not support large files. > Do you mean to say FBSD's implementation of cd9660 doesn't support large files? Because using mkisofs I seem to have a 4GB limit, but that limit doesn't appear to exist with UFS2 or ext3 in FBSD. -- indi Google Groupers and X-posters are filtered. If you're not a troll or a spammer then you might want to stop posting like one.
From: Indi on 17 Jan 2010 12:28
On 2010-01-17, Joerg Schilling <js(a)cs.tu-berlin.de> wrote: > In article <7rgq1mFgdlU1(a)mid.individual.net>, Indi <indi(a)127.0.0.1> wrote: >>On 2010-01-17, Joerg Schilling <js(a)cs.tu-berlin.de> wrote: >>>>It appeared I had made and burned an iso with an 8GB tar file in it, >>>>upon closer inspection only 4GB actually went to disk but it went twice. >>>>I got 2 duplicate (not split) 4GB archives on the disk. >>> >>> If this is true, then the FreeBSD kernel does not support large files. >>> >> >>Do you mean to say FBSD's implementation of cd9660 doesn't support >>large files? Because using mkisofs I seem to have a 4GB limit, but that >>limit doesn't appear to exist with UFS2 or ext3 in FBSD. > > We are currently talking about ISO-9660. For this reason, I don't care on > whether other filesystems support large files. Well ok, but IMO you did make an absolute statement which could easily be misunderstood. :) > If you see more than one > directory entry with the same name, then FreeBSD seems to ignore the > multi-extent flag in the ISO-9660 directory entry. > Testing further I find no problem writing files as large as 8GB (max size I tested) in FreeBSD using mkisofs with "--iso-level 3 -udf" options (and mounting as udf). Thanks very much for your work on this software, Joerg. The functionality you've provided is invaluable. Cheers, -- indi Google Groupers and X-posters are filtered. If you're not a troll or a spammer then you might want to stop posting like one. |