12:52 a.m.
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
6:53 a.m.
-----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!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk6z0i4ACgkQqbQrVW3JyMQbDwCdFdUfXf0RlG4+llKZFTYFfX/U
7o0Anjkpj/83TmvvtMa0yzLVLtLyMbc1
=JLJr
-----END PGP SIGNATURE-----
1 a.m.
New subject: [SOLVED:] k3b [WAS: Re: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]]
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
5:13 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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
4:46 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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
7:19 a.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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
6:19 a.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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.
--
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quixote(a)dulcineatech.com
11:50 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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(a)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(a)lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
1:54 a.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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 Newell<pnewell(a)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(a)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
10:36 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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
10:26 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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! :)
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
"For the word of God is living and active. Sharper than any double-edged
sword, it penetrates even to dividing soul and spirit, joints and marrow;
it judges the thoughts and attitudes of the heart."
---------------------------- Hebrews 4:12 (niv) ------------------------------
10:24 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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
10:22 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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.
--
-------------------------------------------------------------------------------
Under no circumstances will I ever purchase anything offered to me as
the result of an unsolicited e-mail message. Nor will I forward chain
letters, petitions, mass mailings, or virus warnings to large numbers
of others. This is my contribution to the survival of the online
community.
--Roger Ebert, December, 1996
----------------------------- The Boulder Pledge -----------------------------
10:04 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brasero (maybe bug)]
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
8:51 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brassero (maybe bug)]
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
7:32 p.m.
New subject: gnomebaker [WAS: Re: question(s) on Brassero (maybe bug)]
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
5:18 p.m.
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
4577
days inactive
4579
days old
16 comments
5 participants
participants (5)
-
Don Quixote de la Manvha -
Fred Smith -
Mikkel L. Ellertson -
Patrick O'Callaghan -
Paul Allen Newell