X.4.11 "Make sure that your startup disk has no spaces or special char

[etyrnal]

On OS X.4.11...

Instructions say "Make sure that your startup disk has no spaces or special characters in its name."

We need to rename our volume just to get an app to run?? Why?

Doesn't ffmpeg know how to handle escaping spaces?

isn't ffmepg teh app that creates the commandline instructions?


if i rename my volume, that's going to break paths for a WHOLE lot of other apps and server processes...

seems silly to cater an entire system to a single app and it's supporting apps...

what workarounds are there?

is it the supporting binaries that 'need this' ?

of ffmpeg that can't handle it??

i don't think i've even noticed it being a problem, but maybe i haven't encountered it yet...

right now i'm converting an .avi to DVD - seems to be working...

but it's only generating the video - no audio (yet?)...

WHen would i see a problem manifest pertaining to the white spaces?

[etyrnal]

What if i'm NOT using the Startup Volume for for storage and scratch??

I use an external drive.

Can't THAT drive have the "no spaces rule" ??

[Case]

It is a safety precaution to avoid problems with some tools that are part of the ffmpegX toolbox.
• ffmpeg handles spaces just fine.
• mencoder/mplayer has trouble with spaces if the volume of the source or destination file has spaces
• mpeg2enc w/ Decode with QuickTime/Decode with ffmpeg handles spaces just fine
• mpeg2enc w/ Decode with mplayer can complain about spaces
• x264 handles spaces just fine.
• some tools use a relative path (/.../.../...) for files on the boot volume, ignoring that volume name
• files on different volume always use the volume name as part of the path
• ...

You can get away with a lot, but some operations can fail, depending on location of files.
I understand it has to do with some of the tools not accepting escaped strings or decoding the escaped string before handling it, or something like that. As these routines are hardcoded in the binaries, it couldn't be done with the inclusion of these tool "as-is".

[etyrnal]

thanks for your awesome reply...

what if the Volume where the source and destination files/directories/pathnames have NO SPACES... might it be safe in THAT case?

[Case]

I haven't tested every possible combination of tools, but my first impression is yes, that might just work.