Long PC File Name Fix?

kdec_2

Member
Hi, anybody know how to stop long file names from changing and adding the " ~ "?

It's becoming more of a problem now that we use and Esko Rip... copy the job files to the PC and then if we copy them back to the Mac to edit, it shortens the file names and makes them ALL CAPS and ends with a " ~ ".

Using OS X Tiger

Found online info on this old control panel called Joliet Volume Access, but that was for OS 9.

thanks for any help!
 
Re: Long PC File Name Fix?

Windows hasn't had the Services for Mac updated in many years (I don't think it ever was since AFP-compliance was added to Windows with Services for Macintosh). So since the version on your rip running Windows is much older than on your Mac (I'm sure this is on purpose by Microsoft not to keep it updated), then you can connect to Windows machine from Mac via AFP and long filenames will be seen as truncated. Or you can connect via SMB and have all your Mac files that were dropped on their when connected via AFP be seen as Unix executables (cause not seeing a resource fork, because Windows doesn't honor the resource fork), but see long filenames. Not a good choice at all.

So that's why there's third-party products such as MacServerIP9 and also ExtremeZ-IP to overcome Microsoft's crippling of AFP (by not keeping it up-to-date). Install one of these products on the server/rip and you won't have these problems any longer. Or you can just deal with the filename length, or can manually rename with 'A Better Finder Rename 7'.

I guess you can tell I've had the same problems, and why I'm to the point of never letting another Windows application or IT person in this building if I can help it. Apple and Mac all the way baby! (Much cheaper to by an external Firewire HD for storage than calling IT and getting reamed by the high prices for everything, and then have to buy one of the above programs so that your Mac jobs can be kept on a Windows server, when you can bypass this crap and just format an external FW HD as Mac format and not have to do any of this. But if you use a Mac and gotta deal with Windows in any way, you might as well except that you'll have to "smarten up" your Windows machine to deal with Mac, or "dumb down" your Mac to deal with Windows.

Don
 
Re: Long PC File Name Fix?

Thanks for the reply! And I can sence your frustration, ha! And I agree, the FW HD might be the easiest/best way to go.

Thanks!!

EDIT: Actually I just did a little more googling on this problem, found this free app. called "Classic31". Drag n Drop folders on it and it'll let ya know if there are more then 31 characters in the file names, tells ya how many ya need to delete and lets ya change the file name all in the same window.

Pretty Cool huh?

Edited by: kdec_2 on Jan 14, 2008 8:23 AM
 
Re: Long PC File Name Fix?

Hmmm... Don't know if they've update Extreme-Z but my version still doesn't support all the filenames the Mac OS can. It'll just throw a an error ( -50 I think ) at the mac. Better than truncation but still not a panacea. SFM has been "updated" in some ways but those critical differences between the NTFS and HFS+ will never go away.
 
Re: Long PC File Name Fix?

Leopard really doesnt work with ExtremeZ

I am using it but it drops the network connection and you have to reconnect to servers every 10 minutes or so

It just times out then you can see the folders on root but folders appear empty and you can write to them
 
Re: Long PC File Name Fix?

Yeah, but the character limit is not the only problem. There's also a problem with certain characters, which with 'A Better Finder Rename' get changed to underlines. Since installing MacServerIP though (bought like 3 or 4 licenses, where ExtremeZ-IP I would have had to buy minimum 10 licenses I thik was on their website), I haven't had any problems (and of course don't have to rename anything before moving it to the Windows/MacServerIP share).

Don
 
Re: Long PC File Name Fix?

say you use one of these programs to shorten file names of 50 images placed in ID. Would the links update automatically? Is it possible to update to the incorrect image?
 
Re: Long PC File Name Fix?

> {quote:title=macdudeken wrote:}{quote}
> say you use one of these programs to shorten file names of 50 images placed in ID. Would the links update automatically? Is it possible to update to the incorrect image?


No and yes.
 
Re: Long PC File Name Fix?

Why not log into the Windows server from your Mac OSX using CIFS protocol and enjoy the same 250 character file names that have been standard on Windows for years.

Finder --> File Menu --> go --> connect to Server

(or command-K)

enter:

cifs://<windows server name>/<share name>

(swap in the proper names)

Let AppleTalk die already, along with its 31 character limit. The protocols day has come and gone.
 
Re: Long PC File Name Fix?

> {quote:title=William Campbell wrote:}{quote}
> Why not log into the Windows server from your Mac OSX using CIFS protocol and enjoy the same 250 character file names that have been standard on Windows for years.
>
> Finder --> File Menu --> go --> connect to Server
>
> (or command-K)
>
> enter:
>
> cifs://<windows server name>/<share name>
>
> (swap in the proper names)
>
> Let AppleTalk die already, along with its 31 character limit. The protocols day has come and gone.


To quote Don Isbell on post #2 in this thread:

"Or you can connect via SMB (My addition: or CIFS) and have all your Mac files that were dropped on their when connected via AFP be seen as Unix executables (cause not seeing a resource fork, because Windows doesn't honor the resource fork), but see long filenames. "
 
Re: Long PC File Name Fix?

CIFS is fully capable of preserving resource forks on a Windows server.

You may be misinterpreting Don's note. Or he could have elaborated.

For files that were *previously* stored via AFP on a Windows server, using MS Services for Macintosh, resource forks are stored within a second file stream (NTFS feature of Windows since Advanced Server 3.1, circa 1994). At the Windows server (or other Win workstation for that matter), all files, even Mac files (and their resource forks) appear to exist within one physical file, since they do. Data in one stream, resource in a second stream.

However, mount that same Windows share via cifs and you will not get access to those resource forks. No fault of the server, protocol, or anything else. It's just a matter of data stored one way, and when accessed by a foreign means (cifs vs afp) the scheme doesn't work.

So do this -- Take a share on Windows, and also share the same folder using "Services for Macintosh" (AFP). Give it another name or it gets confusing. For example, what we do: "JOBS," a Windows share that Win workstations and OSX clients (via cifs) access, and the same folder shared via afp as "JOBS~AFP."

For the older files, copy these FROM the afp volume TO the cifs mount of the volume. (can't copy directly over itself though, watch out. make up new folders or whatever).

Now those old resource forks will work. For new files, forget afp and put them on the server via cifs from now on.

There is much already written about this topic. OSX now has its own means to store resource forks on foreign files systems, so it no longer needs Microsoft's "Services for Macintosh." But how it does it is different. Users must stay aware of that. OSX will add another hidden file, the same name prefixed with "._" in which the resource fork is stored. You won't see these at Windows without enabling show hidden files. Then they appear, but look grayed-out in explorer.

The only downside of using cifs versus afp is that Mac users are limited to legal Windows characters. ? nor / are allowed for example. In my opinion (others may certainly vary), the loss of those few characters is far less pain than being limited to 31. And I use Better Finder Rename to correct any problem file names that come along (it's actually quite rare now). Don also mentioned this, we have discussed the subject before at length. Check the archives, there is lots to know about cifs versus afp. Our prepress operation runs exclusive cifs on every Mac (all OSX).
 
Re: Long PC File Name Fix?

Still convulted and is no fix. I can do the same thing with SMB.
 
Re: Long PC File Name Fix?

For OSX, SMB and CIFS are synonymous.

And how is it not a fix? Perhaps not for old files that have already had their names whacked (truncated to eight characters with tildes followed by a number), I will grant you that. But knowing how to deal with files from now on (avoid AppleTalk), that problem is averted in the future.
 
Re: Long PC File Name Fix?

> {quote:title=William Campbell wrote:}{quote}
> For OSX, SMB and CIFS are synonymous.
>
> And how is it not a fix? Perhaps not for old files that have already had their names whacked (truncated to eight characters with tildes followed by a number), I will grant you that. But knowing how to deal with files from now on (avoid AppleTalk), that problem is averted in the future.


The problem is having to have two shares to copy to. That, to me, is a kludge. Not a fix. And that's why our current Windows file server will be our last.
 
Re: Long PC File Name Fix?

I'm quessing that Joe is missing the point that once all your files have been transfered to the CIFS volume you no longer need the AFP volume, right?

What are the file/folder character restrictions for CIFS? I tried goggling for more info but got lost in the geek speak.
 
Re: Long PC File Name Fix?

> {quote:title=GinSu wrote:}{quote}
> I'm quessing that Joe is missing the point that once all your files have been transfered to the CIFS volume you no longer need the AFP volume, right?
>

Right. It may be convoluted, possibly a kludge, but I only offer the insight in the hope of aiding those who are facing this "new way versus old way" and may have otherwise concluded, oh hell, I lost it all (the resource forks). What I offer is a means to restore them, if what I describe happens to be "the why" that they are lost. There can be other reasons, but the introduction of SMB/CIFS combined with Windows servers previously using SFM is largely responsible for most cases.

I had encountered one instance where a company was doing "hand-me-downs" of their OS9 Macs, passing the lower powered workstations off to the preflight department as the prep dept got new OSX machines. Suddenly they had this problem where all the fonts were zero K and couldn't figure it out. The why: preflight copied all jobs onto the windows server, and since OS9 has no other choice than AFP, it was all via MS Services for Mac. The prep dept was logged into the sever over SMB/CIFS. Like talking two different languages. Once I explained all I have been explaining here, all was well.

Thank you for pointing out the misunderstanding. You are quite correct, once no further files are stored by the old MS Service for Mac method, there will no longer be any need for this kludge. And neither is there any need for AFP shares, or even that kludgy protocol, AppleTalk. Copy files on via CIFS and access them via CIFS and all is well. You get both long names and resource forks.

As for illegal characters, I will list some of the most common I have encountered, but there certainly could be others more obscure. Most likely the best place to get a definitive answer is from something pertinent to Windows.

/ \ | ? * < > "

Also colon : which is already illegal on Mac (path separator, as is backslash for Windows/DOS).

Windows also does not allow any file or folder name to end with the space character, as does Mac (which it never should have, because it creates names that "look" identical while they actually are not).

Given that short list, versus gaining 250 characters (including path) versus 31 characters, not to mention the higher performance of SMB/CIFS over any flavor of AppleTalk, why would anyone stick with AppleTalk just to have those few characters available?
 
Re: Long PC File Name Fix?

Okay, maybe I'm missing something but if a customer sends me a sit file containing native documents including fonts and I copy that sit file to a SMB/CIFS share and uncompress it there what happens to the fonts?
 
Re: Long PC File Name Fix?

> Okay, maybe I'm missing something but if a customer sends me a sit file containing native documents including fonts and I copy that sit file to a SMB/CIFS share and uncompress it there what happens to the fonts?
>

They decompress and are ready to use, resource forks intact. I do it daily.

The misconception is that CIFS won't behave like AFP. It will, only better (faster and long names). The apparency that it won't work or drop resource forks comes from mixing the two protocols within a single work environment (copying one way and accessing another). If you copy the sit via CIFS and decompress at the same workstation, or another connected via CIFS, it all works. What happens is that many prep departments are ignorant of these differences in network protocols and have their Macs (even OSX Macs, since they can log on either way) mounted to the server in different manners. One is CIFS, another AFP, the next one who knows what. THAT is what causes the problem. Decide on the standard means by which ALL Mac workstation will log into the server and enforce it. Problem solved. That's why I suggested changing the name of the Mac share (old mac share using MS SFM) to something different. That triggers the old "Huh? What changed here?" and operators more easily realize they are not logging in correctly.
 
Re: Long PC File Name Fix?

After reading this yesterday, I've started using CIFS on all our Macs and haven't experienced any issues
at all. This is one of my boss' pet peeves, so if it works he (and I) will be very pleased. We're at a small shop
so implementation was a snap. Sounds a bit too good to be true after using PC MacLAN for so long. I'd
love to give AFP the boot.
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top