Line type 1 and 0 FILE filename/part name upper/lowercase specification

[Mario Pascucci]

Hi (again) all, people.

I'm still working on a simple Java renderer for LDraw models, and now I'm a little confused about part/filename/subfile/"0 FILE" MPD extension/etc. for case sensitivity.

- In "File Format 1.0.2" there are no statements about case-sensitivity for file names or line type "1". Only in "Direct color" ("hex values must be uppercase") and "File Type" (case insensitive).

- In "File Format Restrictions for the Official Library" under "LDraw Files/File Name" it states "While both upper and lower case letters are permitted in filenames, filenames are case-insensitive. Currently, all official parts are issued with upper-case only names." But in "complete.zip" official library all part/subpart/primitive names are lower-case!

- Zip files are case sensitive (and so are developer libraries to access Zip files), and when extract files in a case-sensitive file system use original-case filenames. Search file names in ZIP file is case sensitive, so it is important to know how a part/subpart/primitive file is named in official library: 3070b.DAT, 3070B.dat or 3070B.DAT are different.

- Looking at "MPD Language Extension", filename case isn't specified. But in a forum message (here) it is clearly stated that "And MPD file lookup probably shouldn't be case-sensitive, because no other filename lookups in LDraw files are case-sensitive".

So, my questions:
- Can I assume that in MPD-type file all internal references to sub-file can be case insensitive?
- Can I assume that part/subpart/primitives file names in Official library are all lowercase?
- LDR-type file with external reference to sub-file needs to be case-sensitive, because now almost all filesystem are case-sensitive. So, can I consider external referenze to sub-file are case-sensitive?

Thank you for your great work on LDraw libraries!

Mario
PS: when my Java viewer is ready I'll share it with you.

[Roland Melkert]

I know it's a pain, but you need to handle all references case insensitive, even on case sensitive file systems.

It's also a good idea to accept both '\' and '/' directory separation characters.

[Chris Dee]

The Parts Tracker, when the part updates are built, runs FreeBSD UNIX, so filenames are case-sensitive and always lowercase. The the "0 Name: " line must match that.

Since the original deployment of the LDraw library was Windows, it never mattered what case was used in line type 1 references and no convention is enforced. The convention is to use Windows-style (\) directory separators, although I just found a few parts that don't follow that, so I suspect it is not rigourously checked durig the parts update build.

I think Roland is right that to support tools should be insensitive to case and directory separator.

There was a special case that an all-uppercase reference to STUD.DAT was meant to instruct the renderer never to substitute low-res or no-res studs, where this primitive was used for things like door handles, etc. I doubt this was well documented, may not have been implemented beyond the (now obsolete) ldraw.exe program and probably isn't understood by part authors (cf. 6104.dat).

Chris

[Travis Cobbs]

The Qt version of LDView has special handling for "file not found" where it does a fully case-insensitive search for the file after it fails to find the file using the case inside the LDraw model and all lower case. Unfortunately, actually performing the case-insensitive search is relatively slow on most *nix systems, but it is sometimes necessary. The command line-only version of LDView (used for creating snapshots and nothing else) simply tries the original case from the LDraw file and then tries all lower case. Fully case-insensitive is definitely preferred, but possibly not necessary, as long as you have a fallback that checks the reference with all lower case.

I know you didn't mention it, but I also have a comment about '/' vs '\'. It's a little know fact, but programs running in Windows can use '/' as a path separator for everything except for the "\\" that comes at the beginning of special paths like network paths. As far as I know, the only places '\' is required by Windows itself is on the command line, and for the "\\" prefix for special paths. So I have LDView internally convert all '\' characters found in LDraw type 1 lines to '/' on all operating systems.

[Roland Melkert]

In LDCad I cache directory listings in (sorted) string lists and do case insensitive searches on those. This is done for both the windows and Linux versions. Only down side is when the file exists in multiple cases on the file system. First one will win in that scenario, maybe i make it an option some day to do the literal check first but I think it's just a waste of the time in 99.9% of cases.

Just for fun I opened the 5571 model and let wingrep count the number of case mismatch warnings in the log, there were 376 occurrences

[Mario Pascucci]

Hi people.
First of all, thank you all for explanation, and for your advice, I know, you worked on LDraw library long before me ;-)

To recap:
- all part search in LDraw library MUST be case insensitive (with exception for STUD.DAT all upper-case)
- all file search is PREFERRED to be case insensitive, or, at least, case sensitive search followed by "all lower" search
- all part and file references can use both '/' or '\' for path separator

Now, assuming too many isn't a good programming practice, so I will review my part and file reference search code to be as generic as I can do.

What my code already do:
- both '\' or '/' in line type 1 references are accepted
- search in MPD internal references are case insensitive

What to do:
- external reference to file will be case insensitive (if duplication occurs, first win)
- search for LDraw part in libraries will be case insensitive (see note below for STUD.DAT special case)


A marginal note: IMHO the STUD.DAT rule (Chris, it isn't in any spec I've look at) is a little confusing for "case-insensitivity" rule in all the library spec. IMHO can be more useful a group of primitives with a suffix (like "fix": studfix.dat that references 4-4edgefix.dat, 4-4cylifix.dat and 4-4discfix.dat) without low or high resolution counterparts in 8/ or 48/ subdir.


Thank you again.

Mario

PS: a little fun with stud.dat casing in library:
- STUD.DAT is used in 13 parts: 189.dat 30255.dat 30414.dat 3127b.dat 4151b.dat 47844.dat 50303.dat 50949.dat 511.dat 6003.dat 60471.dat 60478.dat 6104.dat and in 1 sub-part: s/30225bs1.dat
- stud.DAT is used in 6 parts: 2573.dat 2574.dat 3010p21.dat 4082.dat 721.dat 883.dat

[Steffen]

I think, please ignore the stud.dat capitalization technique.
Nobody is aware of that, and it would introduce a total new mess of confusion.

[Chris Dee]

I agree. Ignore the STUD.DAT "convention" - it was little known, is undocumented and has already been incorrectly used (hence my example of 6104.dat).

If people think it is important, there are other ways to achieve that end.

[Mario Pascucci]

Ok, got it.

No stud.dat capitalization "convention" ;-)

Thank you.

Mario

[Mario Pascucci]

@Roland & @Chris:
I totally agree for case insensitive search for :
- parts in library
- sub-file references in MPD files

I see only a little drawback on using case insensitive sub-model search in the situation of a multiple sub file project, suppose this situation in a case sensitive filesystem (*nix-like):
- a model called "model.ldr" with some sub-model called "model-a1.ldr" "model-a2.ldr" "model-b1.ldr" "model-b2.ldr"
- a model called "model-B1.ldr" in the same directory

If a program will do a case insensitive search to read model.ldr there is a chance that you will get
"model-B1.ldr"
instead of
"model-b1.ldr"

There is also a risk that user reads "model-B1.ldr" model and save it as "model-b1.ldr" if program matches first "model-B1.ldr" on read.

Windows have a case-preserving filesystem, but file search are case-insensitive, so exposed situation is impossible on Windows (if you have "model-B1.ldr" and try to save another file with name "model-b1.ldr" in same directory you'll get an overwrite warning).

So... my point of view (absolutely arguable) it is to leave to the user to solve this problem if an automatic solution can be dangerous or can lead to unexpected results.
It will be a problem only on case sensitive filesystem (*nix-like), not on Windows and OSX (see here).