MPTCFS~ only accepts a truncated filepath

[klangfreund]

hi,



I use Topher LaFata's new filebrowser as well as the 'Drop Region for Files' to get the file I wanna scratch with MPTCFS~.

But if the whole filepath is too long these two gives me different results:



filebrowser:

"OSX:/Users/sam/data/res/audio/cat not copied/beautiful/Boomclick - High Tide (Original).mp3"



drop Region:

"OSX:/Users/sam/data/res/audio/cat not copied/beautiful/Boomclick - High Tide#4B70C.mp3"



MsPinky's MPTCFS~ only accepts the path from 'drop Region'.

dlpinkstah, may you change the MPTCFS~ slightly, so that it will accept both versions?



Does someone know how to get the truncated (like drop Region delivers) version from the plain path version?

What rule lies behind this "#4B70C"?



I'm working on Mac OS X 10.4.2

[klangfreund]

btw. the mentioned filebrowser is available at http://www.cycling74.com/share/topher/.



I already got a reply from Peter Castine in the maxmsp-list:

Code that accesses the file system using system calls from before HFS+ are limited to 31-char file names. HFS+ "mangles" longer names to a unique 31-char name. HFS+ will only resolve the mangled name to the real name when using the old system calls. I am not aware of any documentation of exactly how HFS+ mangles file names.



So: use only objects that use the new file system calls, or only objects that use the old system calls. Ms. Pinky apparently uses the old calls, as does DropRegion.



Or, follow Emmanuel's advice and avoid long file names.



You might ask Topher if he would add a "usebackwardscompatiblefilemangling" attribute to filebrowser.

and by Nick Rothwell:

If Topher's code is pure Java, I'd be surprised if any recent JVM

doesn't support long filenames...

dlpinkstah, may you add that filename issue to your todo-list for MPTCFS~?

[dlpinkstah]

OK. I understand the problem you're having and I can fix it. But first I want to make sure we all can agree on the solution. Here's what I propose:



Because I make heavy use of drop-file regions in my patches, I need to continue to support whatever they output as the default way of handling filenames, though as you have shown these file names are mangled in OSX. However, you may or may not have noticed that if you query MPTCFS~ for the filename of any file you open in OSX it will not come out mangled! This is because internally Ms Pinky is bending over backwards and doing 3 summersaults to fetch the full non-mangled filename. So what I think I will have to do is to introduce a new "read_OSX_extended" command to the OSX versions of MPTCFS~ and MPFS~ so that they will accept the input as a literal full-pathname instead of trying to do its internal conversion acrobatics. OK?

[klangfreund]

that would be superb!



auto-detection would be even a tiny little bit sweeter... But only if it's a no-puzzler on your side!!

I'm working on a Pluggo-Plugin for Miss Pinky and use the Plugin Parameters that every host supplies for storing the filepath (after conversion into some numbers). That way the last timecode controlled file will be auto-loaded if a project will be reopened in the host software. Because this plugin accepts drag n drop as well as filebrowsing, I'd also would need to store the "extended filename or not" information as a Plugin Paramter. Well, that's of course not such a big effort, but auto-detection would make it just a tiny little bit easier.