LDraw.org Discussion Forums

Full Version: Spaces in filenames
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Michael Heidemann pointed out that the newly created OMR spec requires that filenames contain spaces, while the pre-existing LDraw 1.0.0 spec strongly discourages spaces or tabs in filenames. He (quite rightly, in my opinion) felt that this was inconsistent.

So, the way I see it, we have three choices:
  1. Ignore the problem.
  2. Remove the discouragement text from the LDraw standard.
  3. Change the OMR standard so that the filenames don't include spaces.

My vote is to do go with option 2, at least for spaces. I think tabs should still be discouraged, since they just seem like a bad idea in filenames (assuming they're even valid on all OSes). Please note that the official parts restriction document already disallows spaces in the filenames of files in the library, so this won't affect the parts library. (More specifically, it lists the only allowed characters, and spaces, tab, etc. are not listed.)
I would also go for option '2' because all major filesystems support spaces these days. Also I don't think people will stop using them anyway.

But you bring up another issue: not all filesystems have the same 'bad character' sets. So are we allowing the full unicode set and let the software/os handle wrong names or do we define the bad ones somewhere in full?

The current 1.0.0 only mentions a couple of 'bad' characters (it doesn't list : and * for example). So maybe add a full list based on e.g. fat32, ext2, ntfs (and other major fs's).
I'd go for option 2 and allow them for .ldr and .mpd. I would keep them however for official .dat files.

w.
I go with Option 2.

A disclaimer that some older programs may choke on spaces is fine. But if there's still an actively-maintained program that does, I consider that a bug.

To take this even further, imposing any restrictions on user-controlled file names is not realistic. The user gets to enter a filename in a save dialog, or in the filesystem browser. LDraw programs have no control whatsoever over what a user names his files. It's up to the user to discover (the hard way) that some filesystems prohibit certain characters.

Allen

Fun Fact: On Mac OS 9, it was possible to generate filenames which contained '\0', since all strings were stored Pascal-style (length byte followed by chars). Suffice it to say that would not go over well on any system with a C heritage.
I'm happy with option 2.

Chris
Any more comments on this? If not we may vote on this?

w.
Besides the listing of 'special chars' (yes / no) everybody seems to agree.
Roland Melkert Wrote:
-------------------------------------------------------
> So
> are we allowing the full unicode set and let the
> software/os handle wrong names or do we define the
> bad ones somewhere in full?
>
> The current 1.0.0 only mentions a couple of 'bad'
> characters (it doesn't list : and * for example).
> So maybe add a full list based on e.g. fat32,
> ext2, ntfs (and other major fs's).

Since I'm not a programer it is not my sandbox but I'd go with a set that is supported by the largest number of FS.

w.
The list should (at least) include:

':', ';', '*', '?', '|', '%', '"', '>', '<', "\0", "\t", '\' and '/'

Though '\' or '/' has an exception when it's the dir sep on the current platform. But it still technically can't be part for the file name, it part of the file path.

Also the list should stay a 'guidance', because software could implement escaping to allow just about anything if the fs supports it.

see also:

http://en.wikipedia.org/wiki/Filename

edit: I forgot ';'
I'm fine with it. Guys?

w.
Pages: 1 2