I am trying out burning DVDs on F14 and I am seeing some weirdness that I would like to understand before I call it a bug.
I burn a directory on F14. The directory structure is deep (as in greater than the pop-up notice of 7) and the names should be within 60 characters. Brassero asks me about renaming to be Windows compatible owing to 64 characters and I disable since no files should hit that limit (and testing later indicates there are no 64+ file names). Brassero gets all wound up over the depth of the directory tree and I tell it just add them.
The burned disk is exactly what I would expect on Linux/F14
On Windows, it is a useless work of whatever. It can't read anything and everything is all CAPS. I know that Windows is an all CAPS under the hood from long ago ... but I've been able to work case-sensitive on my XP for awhile.
Since I have to assume that I am not understanding things, can anyone tell me how to use Brassero to get a exact copy? The Brassero->help just tells me about the pop-ups I already see.
I can burn a DVD on Windows XP with Nero that is readable on Windows and Linux, hard to believe that native Fedora can't do the same (???)
I do not want to burn an iso ... I want a DVD burn which I can access as a normal Linux/Window directory.
Thanks in advance, Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/04/2011 12:52 AM, Paul Allen Newell wrote:
I am trying out burning DVDs on F14 and I am seeing some weirdness that I would like to understand before I call it a bug.
I burn a directory on F14. The directory structure is deep (as in greater than the pop-up notice of 7) and the names should be within 60 characters. Brassero asks me about renaming to be Windows compatible owing to 64 characters and I disable since no files should hit that limit (and testing later indicates there are no 64+ file names). Brassero gets all wound up over the depth of the directory tree and I tell it just add them.
The burned disk is exactly what I would expect on Linux/F14
On Windows, it is a useless work of whatever. It can't read anything and everything is all CAPS. I know that Windows is an all CAPS under the hood from long ago ... but I've been able to work case-sensitive on my XP for awhile.
Since I have to assume that I am not understanding things, can anyone tell me how to use Brassero to get a exact copy? The Brassero->help just tells me about the pop-ups I already see.
I can burn a DVD on Windows XP with Nero that is readable on Windows and Linux, hard to believe that native Fedora can't do the same (???)
I do not want to burn an iso ... I want a DVD burn which I can access as a normal Linux/Window directory.
Thanks in advance, Paul
What you are getting is the standard CD/DVD mode for Windows. It is the equivalent to the FAT file system, as opposed to the VFAT file system. If you want case sensitive names, you need to allow Windows compatibility. The prompt is misleading that way.
I normally use GnomeBreaker to burn CD/DVDs. The windows compatibility mode (Juliet file system) is enabled by default. So is the Rockridge file system for Linux name support. You can still read CD/DVDs without the Rockridge file system. Linux know about the Juliet extension to the standard CD/DVD file format. You just do not get the Unix file attributes.
Mikkel - --
Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
On 11/4/2011 4:53 AM, Mikkel L. Ellertson wrote:
I normally use GnomeBreaker to burn CD/DVDs. The windows compatibility mode (Juliet file system) is enabled by default. So is the Rockridge file system for Linux name support. You can still read CD/DVDs without the Rockridge file system. Linux know about the Juliet extension to the standard CD/DVD file format. You just do not get the Unix file attributes.
Mikkel
Mikkel:
Thanks for advice. I am presuming you meant Gnomebaker, not Gnomebreaker?
Yeah, the prompt is confusing and it caused me to focus on the 64 character length issue (I know I have some long names in the directory tree that come in under Nero 97 char limit which I thought was Joliet limit). I haven't heard the name Rockridge, but googling it makes it clear that I've been dealing with at least some aspects of it thinking they were part of Joliet.
Paul
On 11/4/2011 3:18 PM, Paul Allen Newell wrote:
On 11/4/2011 4:53 AM, Mikkel L. Ellertson wrote:
I normally use GnomeBreaker to burn CD/DVDs. [...]
Mikkel
Mikkel:
Thanks for advice. I am presuming you meant Gnomebaker, not Gnomebreaker?
[...]
Paul
Gnomebaker is not going to work as it barks about too great a directory depth. The mkisofs command (which appears to be genisoimage in the man page) it executes has -iso-level 3 and -joliet-long, but regardless of joliet and/or rockridge settings, that doesn't seem to be enough to get around the directory depth. It looks like I need ISO 9660:1999 but the gnomebaker doesn't seem to give me a way to make iso-level = 4.
One interesting thing is I couldn't get any of the edit->preferences to stick, the window just says close and change isn't saved (was trying the force depth option).
Oh well, scp to Windows box and using Nero there is the path of least resistance ... but I at least know more about ISO 9660 ...
If someone can point out that I am missing something obvious, I'd love to be corrected ...
Thanks, Paul
On Fri, 2011-11-04 at 17:32 -0700, Paul Allen Newell wrote:
On 11/4/2011 3:18 PM, Paul Allen Newell wrote:
On 11/4/2011 4:53 AM, Mikkel L. Ellertson wrote:
I normally use GnomeBreaker to burn CD/DVDs. [...]
Mikkel
Mikkel:
Thanks for advice. I am presuming you meant Gnomebaker, not Gnomebreaker?
[...]
Paul
Gnomebaker is not going to work as it barks about too great a directory depth. The mkisofs command (which appears to be genisoimage in the man page) it executes has -iso-level 3 and -joliet-long, but regardless of joliet and/or rockridge settings, that doesn't seem to be enough to get around the directory depth. It looks like I need ISO 9660:1999 but the gnomebaker doesn't seem to give me a way to make iso-level = 4.
One interesting thing is I couldn't get any of the edit->preferences to stick, the window just says close and change isn't saved (was trying the force depth option).
Oh well, scp to Windows box and using Nero there is the path of least resistance ... but I at least know more about ISO 9660 ...
If someone can point out that I am missing something obvious, I'd love to be corrected ...
I've not been following this thread, but is "try k3b" too obvious? (apart from pointing out that it's Brasero, not Brassero).
poc
On 11/4/2011 6:51 PM, Patrick O'Callaghan wrote:
I've not been following this thread, but is "try k3b" too obvious? (apart from pointing out that it's Brasero, not Brassero).
poc
Poc:
My bad on spelling of Brasero ... thank you for correction.
As for k3b, its for KDE if I am correct? I'm on F14 under Gnome.
Appreciate the suggestion, Paul
On Fri, Nov 04, 2011 at 08:04:37PM -0700, Paul Allen Newell wrote:
On 11/4/2011 6:51 PM, Patrick O'Callaghan wrote:
I've not been following this thread, but is "try k3b" too obvious? (apart from pointing out that it's Brasero, not Brassero).
poc
Poc:
My bad on spelling of Brasero ... thank you for correction.
As for k3b, its for KDE if I am correct? I'm on F14 under Gnome.
You CAN do "yum install k3b" and it'll install the necessary KDE bits along with k3b. that's the way I always do it.
On 11/4/2011 8:22 PM, fred smith wrote:
You CAN do "yum install k3b" and it'll install the necessary KDE bits along with k3b. that's the way I always do it.
Fred:
I was unaware that kde packages could operate under gnome and vice versa? No conflicts in doing such?
Thanks, Paul
On Fri, Nov 04, 2011 at 08:24:39PM -0700, Paul Allen Newell wrote:
On 11/4/2011 8:22 PM, fred smith wrote:
You CAN do "yum install k3b" and it'll install the necessary KDE bits along with k3b. that's the way I always do it.
Fred:
I was unaware that kde packages could operate under gnome and vice versa? No conflicts in doing such?
I wouldn't expect any, though I'm no guru. I just always do it as above and it works, as if by magic! :)
On 11/4/2011 8:26 PM, fred smith wrote:
On Fri, Nov 04, 2011 at 08:24:39PM -0700, Paul Allen Newell wrote:
On 11/4/2011 8:22 PM, fred smith wrote:
You CAN do "yum install k3b" and it'll install the necessary KDE bits along with k3b. that's the way I always do it.
Fred:
I was unaware that kde packages could operate under gnome and vice versa? No conflicts in doing such?
I wouldn't expect any, though I'm no guru. I just always do it as above and it works, as if by magic! :)
I was googling k3b and gnome when your email came in ... it sure looks like it should work. Alright, another package to try.
My thanks to Poc and Fred for pointing me in this direction (finger crossed that it works), Paul
At one time gnome and kde did not interoperate well because of different conventions for some GUI stuff like the clipboard but those were harmonized long ago.
You don't need all of kde, just the dependencies.
Your problem may be that you are exceeding the maximum length for an absolute pathname on Windows. On UNIX-like systems that length is given by the MAXPATH macro in some C header file. I think the POSIX MAXPATH is 1024, but I would expect the Windows maximum to be less.
If Windows does have such a maximum path length, the msdn website should tell you what it is.
The ISO 9660 format is quite primitive, as the low-level storage only allows for what you could store on media filesystems. If you don't think the path length is the culprit, give UDF a try.
Sent from my iPhone
On Nov 4, 2011, at 8:36 PM, Paul Allen Newell pnewell@cs.cmu.edu wrote:
On 11/4/2011 8:26 PM, fred smith wrote:
On Fri, Nov 04, 2011 at 08:24:39PM -0700, Paul Allen Newell wrote:
On 11/4/2011 8:22 PM, fred smith wrote:
You CAN do "yum install k3b" and it'll install the necessary KDE bits along with k3b. that's the way I always do it.
Fred:
I was unaware that kde packages could operate under gnome and vice versa? No conflicts in doing such?
I wouldn't expect any, though I'm no guru. I just always do it as above and it works, as if by magic! :)
I was googling k3b and gnome when your email came in ... it sure looks like it should work. Alright, another package to try.
My thanks to Poc and Fred for pointing me in this direction (finger crossed that it works), Paul
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
On 11/4/2011 9:50 PM, Don Quixote de la Manvha wrote:
At one time gnome and kde did not interoperate well because of different conventions for some GUI stuff like the clipboard but those were harmonized long ago.
You don't need all of kde, just the dependencies.
Your problem may be that you are exceeding the maximum length for an absolute pathname on Windows. On UNIX-like systems that length is given by the MAXPATH macro in some C header file. I think the POSIX MAXPATH is 1024, but I would expect the Windows maximum to be less.
If Windows does have such a maximum path length, the msdn website should tell you what it is.
The ISO 9660 format is quite primitive, as the low-level storage only allows for what you could store on media filesystems. If you don't think the path length is the culprit, give UDF a try.
Sent from my iPhone
On Nov 4, 2011, at 8:36 PM, Paul Allen Newellpnewell@cs.cmu.edu wrote:
On 11/4/2011 8:26 PM, fred smith wrote:
On Fri, Nov 04, 2011 at 08:24:39PM -0700, Paul Allen Newell wrote:
On 11/4/2011 8:22 PM, fred smith wrote:
You CAN do "yum install k3b" and it'll install the necessary KDE bits along with k3b. that's the way I always do it.
Fred:
I was unaware that kde packages could operate under gnome and vice versa? No conflicts in doing such?
I wouldn't expect any, though I'm no guru. I just always do it as above and it works, as if by magic! :)
I was googling k3b and gnome when your email came in ... it sure looks like it should work. Alright, another package to try.
My thanks to Poc and Fred for pointing me in this direction (finger crossed that it works), Paul
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
I am trying to clean up my directory structure and file length to understand exactly what the problem is
Thanks for the help, I may get back to you on this if it appears your suggestions are within the range of possibilities.
Paul
The find command will easily determine the longest path in your directory tree.
If "~/foo" is the root of the tree that you want to burn, try:
$ cd ~/foo $ find . -print > ../paths.txt
I expect there is some simple combination of command-line tools that would yield the length of the longest line in paths.txt, but I don't know what they would be.
Instead I suggest opening it in your favorite text editor, then scrolling from the top to the bottom of the file. Whenever you see that a line has wrapped, make your window wider. You will likely have to move the left edge of the window offscreen.
Once you get to the bottom of the file, scroll back up to find the line that just touches the right edge of the window. Copy that line to the Clipboard, then paste it into a new file.
The wc command - for "word count" - will tell you how many characters are in that new file. Suppose it is called "longest.txt":
$ wc longest.txt
I was mistaken when I said that the UNIX maximum path length was given by the MAXPATH #include file macro. It's actually PATH_MAX.
The chances are pretty good that PATH_MAX is defined by a C Standard Library header on Windows. While PATH_MAX is a UNIX operating system concept, the Windows C Standard Library more or less attempts to be source-compatible with the simpler kinds of UNIX source code.
If PATH_MAX for Windows doesn't turn up in a Google search and you don't have Visual Studio, there is a free-as-in-beer version of Visual Studio, but that would be a lot of stuff to install just to look up one line in a header file. Instead look for PATH_MAX in the MinGW headers.
MinGW is a port of the GNU toolchain that produces Win32 binaries that is Free as in Freedom. If PATH_MAX is defined for Windows some MinGW header would have it. Quite likely you could find that header where you could get at it with a web browser without having to actually install anything.
In general, UNIX allows directories to be nested to arbitrary depths. It's just that the total length of an absolute pathname is limited. If your file and directory names are shorter, your directories can be nested more deeply.
A while back I discovered a bug in Mac OS X which was quite similar to this, but rather than file paths, OS X has something called a "device path". The device drivers in the OS X kernel are connected in a tree structure, just like a filesystem heirarchy. At the root of the tree is the motherboard driver, at the tip of a branch for a storage device is the name of a filesystem.
The company I was working for developed a storage driver for a client. On PowerPC Macs, our driver worked great. The identical driver source when compiled for Intel would not work at all on Mac Pros, the high-end desktop Macs. It did work on less-powerful Intel Macs such as my MacBook Pro.
A great deal of debugging as well as poring through much of what is fortunately open source determined that OS X' Disk Arbitration daemon - the OS X equivalent of the UNIX automounter - was asking the kernel for the device path for the volume it wanted to mount.
On Mac Pros, but JUST Mac Pros, the hardware was so much more complex and there were so many more devices in the tree that the resulting path would not fit in the fixed-size buffer that the system call allowed. I think that was 512 bytes. There was absolutely no way that length could be increased without breaking binary compatibility with existing programs.
I reported the bug to Apple. They fixed it in the next build of the system somehow, but without increasing the size of the buffer that system call could take.
I never looked into it, but I expect they worked around it by asking for the path one component at a time. That would make Disk Arbitration work just fine, but any other userspace program that depended on retrieving the device path would still break on Mac Pros, and would have to use the same workaround that Apple used for DIsk Arbitration.
On 11/5/2011 4:19 AM, Don Quixote de la Mancha wrote:
The find command will easily determine the longest path in your directory tree.
If "~/foo" is the root of the tree that you want to burn, try:
$ cd ~/foo $ find . -print> ../paths.txt
Awhile back I'd written a python script to flag all files whose total path/base.ext were longer than Nero's 97 limit so I'm adding more tests into that script. As I said in my reply to Poc, I am suspect of my data and want a rich set of stats on it to make sure its clean per k3b iso-level 3 so I can confirm that the crash I am getting isn't my data (or at least that it isn't "to the best of my ability").
I was mistaken when I said that the UNIX maximum path length was given by the MAXPATH #include file macro. It's actually PATH_MAX.
Thanks for the additional info on maximum path length. Looking in cygwin its 4096 with a _POSIX_PATH_MAX of 256. Given that I am trying to stay within maximums that work across the board, the Nero 97 character is the lowest max and that's my target.
I know I have some deep directory structures (10, maybe 11?) and I am seeing iso documentation about 31 character max file name (plus Brasero and k3b want to rename owing to that max). Maybe other stuff that I haven't spotted yet.
I've got alot of learning and hopefully not too much clean-up.
Paul
I have submitted a bug on k3b regarding crashing on "simulate write" when an actual burn works. Aside from that, it works great (in my opinion, better than brasero and/or gnomebaker). I'm still playing to make sure I am 100% certain, but I think I've got another item checked off on the list of migrating everything from WinXP to F14.
Thanks to everyone who gave advice/suggestions
Paul
On Fri, 2011-11-04 at 20:04 -0700, Paul Allen Newell wrote:
On 11/4/2011 6:51 PM, Patrick O'Callaghan wrote:
I've not been following this thread, but is "try k3b" too obvious? (apart from pointing out that it's Brasero, not Brassero).
poc
Poc:
My bad on spelling of Brasero ... thank you for correction.
As for k3b, its for KDE if I am correct? I'm on F14 under Gnome.
No problem. yum will take care of dependencies when you install it, and it should run fine. For example, I'm writing this in Evolution, even though I run KDE as my desktop (i.e. the other way round).
poc
On 11/5/2011 5:19 AM, Patrick O'Callaghan wrote:
No problem. yum will take care of dependencies when you install it, and it should run fine. For example, I'm writing this in Evolution, even though I run KDE as my desktop (i.e. the other way round).
poc
Poc:
I would agree but as I've got a repeatable and consistent crash I need to wait until I get something for a bug report to see if it really is working. I have this sneaky feeling its my data ... its a quilt-work of material gathered over almost 15 years.
I am actually hoping it does work since my initial test drive has been much better than gnomebaker and brasero (and alot better than "brassero")
Once again, thanks for the suggestion, Paul
-
Don Quixote de la Manvha -
Fred Smith -
Mikkel L. Ellertson -
Patrick O'Callaghan -
Paul Allen Newell