File names - Extreme Zip archives

[steppy]

Time to revisit for upcoming budgeting/purchases.

Has anyone come up with any other solutions for font resources being lost with SMB and long file name truncation with AFP when Macs talk to Windows server? One thing we've toyed with especially when we have lots of files to link is to make a Mac disk image (.dmg) for the job original files and then copy that up to the server. Time consuming but effective.

I understand Extreme Zip from Group Logic is the expensive solution.

Related is getting these Mac and Windows files to offline storage while maintaining font resources and file names. Again Extreme Zip is a strong candidate to facilitate naming and resource forks.

Welcome all ideas and suggestions.

stephen

 

[zombie]

see your PM

 

[GinSu]

You could try CIFS instead of SMB. There are certain characters that don't work in file/folder names and Adobe apps can't see fonts loaded with Suitcases from a CIFS volume (workaround is to copy fonts to HD and load from there). Also can't burn fonts from a CIFS volume to CD/DVD (in OS 10.4.x).

Just something to explore before spending money.

 

[steppy]

Cifs

Cifs

Sorry I don't know how to do that. Is it done at the server or from the Macs?

Sounds like CIFS would substitute one set of name/character issues for another along with a new kind of font problem.

stephen

 

[GinSu]

More CIFS info

More CIFS info

http://printplanet.com/forums/prepr...on/13820-long-pc-file-name-fix?highlight=CIFS

You'll find a lengthy discussion at the above link.

You would connect from the Mac, using "cifs" instead of "afp" in the connect dialog: "cifs://192.168.1.#"

CIFS & AFP handle resource forks differently, so files copied using AFP won't work in CIFS and files copied using CIFS won't work with AFP. This isn't really a problem since most files have extensions, but fonts will be a problem.

We are using AFP except when the filenames are too long and too many, then we copy to our server using CIFS.

Not perfect, but free is good.

 

[steppy]

Thanks for the info, I will check it out.

 

[pmhapp]

You could try CIFS instead of SMB. There are certain characters that don't work in file/folder names and Adobe apps can't see fonts loaded with Suitcases from a CIFS volume (workaround is to copy fonts to HD and load from there). Also can't burn fonts from a CIFS volume to CD/DVD (in OS 10.4.x).

Just something to explore before spending money.

CIFS and SMB are the same protocol, no?


(BTW - we use ExtremeZ-IP here)

 

[GinSu]

Smb<>cifs

Smb<>cifs

CIFS and SMB are the same protocol, no?


(BTW - we use ExtremeZ-IP here)

No they are not. It's easy to understand why some would think so since the Mac interface for connecting to either refers to both, "Select the SMB/CIFS shared...".

SMB (Server Message Block) provides no support for resource forks and CIFS (Common Internet File System) does support them.

If, from Windows, you were to view Mac files copied to a Windows volume using a CIFS connection, you would see a "._filename" version of each file and that's the resource fork. If the same files are copied using SMB, no resources are maintained.

 

[pmhapp]

If, from Windows, you were to view Mac files copied to a Windows volume using a CIFS connection, you would see a "._filename" version of each file and that's the resource fork. If the same files are copied using SMB, no resources are maintained.

I ran some tests using a Windows 2003 Server (this is not the one using ExtremeZ-IP), Mac 10.5.5 client, Windows XP client, and Bauer Bodoni Postscript font from the Adobe collection.

First I connected to the Server using AFP and copied the files. Everything looked normal. I unmounted, remounted using SMB. All the fonts became 0k. This was expected. I unmounted and remounted as CIFS. All the fonts are still 0k.

I deleted the files. Remounted as SMB. Re-copied the fonts. All the fonts look normal. Unmounted and remounted using CIFS. All fonts look normal. Unmounted and remounted using AFP. All the fonts are rendered useless, because the ._ files are separate. Okay.

I delete the files. Remounted as CIFS. Re-copied the fonts. All the fonts look normal. Unmounted, remounted as SMB. All the fonts look normal. Unmounted, remounted using AFP. All the fonts are rendered useless because the ._ files are separate files. Okay.

I also viewed the fonts through a Windows XP box after I copied them using each protocol. All three showed the ._ files? ( I do see ._ files viewing the fonts from Windows that were copied via SMB.)

So, in my testing, SMB and CIFS performed the same.
I have screenshots of all of this that I can post somewhere.

Didn't SMB get updated at some point?

 

[GinSu]

I delete the files. Remounted as CIFS. Re-copied the fonts. All the fonts look normal. Unmounted, remounted as SMB. All the fonts look normal. Unmounted, remounted using AFP. All the fonts are rendered useless because the ._ files are separate files. Okay.

The thing to remember is that files copied via CIFS only work when accessed by CIFS. Copying with CIFS, dismounting and mounting with AFP won't work.

I actually have my server mounted twice, one as AFP and one as CIFS. The volumes are easily distinguished form one another since CIFS volume is all caps. By default we handle files through AFP, but if CIFS is required, we'll include an "x" in the job folder name to indicate to use the CIFS volume.

This is not a perfect solution by any means, but it's free. Since you've already made the investment in Extreme-ZIP, I would stick with that. When I next replace my servers, I'll be using Mac OS X.

 

[pmhapp]

The thing to remember is that files copied via CIFS only work when accessed by CIFS. Copying with CIFS, dismounting and mounting with AFP won't work.

I actually have my server mounted twice, one as AFP and one as CIFS. The volumes are easily distinguished form one another since CIFS volume is all caps. By default we handle files through AFP, but if CIFS is required, we'll include an "x" in the job folder name to indicate to use the CIFS volume.

This is not a perfect solution by any means, but it's free. Since you've already made the investment in Extreme-ZIP, I would stick with that. When I next replace my servers, I'll be using Mac OS X.

Exactly. Whatever protocol you choose, you need to stick with it, not mix and match. Why do you use two different protocols?

Anyway, my tests shows that SMB=CIFS, so they can be used interchangeably, no?

 

[GinSu]

NO, CIFS does not equal SMB.

Fonts copied via SMB and accessed via SMB, CIFS or AFP will not work, fonts copied via CIFS will work when accessed via CIFS.

I use both protocols because neither is a complete solution. The expense of ExtremeZIP is greater than the cost a Mac server and both are too costly when compared with some simple management that is free.

 

[GinSu]

Perhaps SMB has been upgraded. When I attempt to connect to a volume via SMB (smb://192.168.1.x), the mac makes an CIFS connection! Now that's something it didn't do before.

I retract my previous statement, SMB does equal CIFS, but it hasn't always.

 

[ReneG]

Would that help?

Cross-Platform File and Print Sharing Made Easy!
Thursby Software: Products

 

[steppy]

thanks all i have some testing to do!

stephen