Topic: E-Smith & filename length

[AFrankel]

With SME 6.0 b3 I have recently encountered a problem moving files from a workstation to the sme server. The Mitle tells me that the filenames are too long. I don't recall ever encountering this with earlier versions, when moving similar files. Does anyone have any ideas, or is there a fix to allow longr filenames?

Thanks

[Michael Smith]

Any chance you might honor us with perhaps a touch more information?  Like, oh, I dunno, what OS on the workstation, how long the filenames, is it one file or many, how are you trying to do the move, etc.?

Or should we just read your mind?

[Andy Frankel]

Gee whiz, that friendly tone is truly encouraging. Just makes me want to
pour my heart out.

The transfer was being attempted from a Mac running OSX 10.2.8 logged onto
an ibay as a network drive. The mitel box is 6.0 beta3 no other updates.
Running PHProjekt, PHPmyAdmin and Typo3 successfully on 3 other ibays.


The transfer's had problems both moving files from the Mac to the E-Smith,
but also on moving between e-smith directories (like from /ibays/web/files
to /ibays/web/html)

There was clearly a problem with uppercase character names (I guess that
untarring them in OSX created different names than would have happened in a
Linux environment). I addressed this by renaming some of the files.

There was also a problem with filenames being too long. The specific case
was in trying to install and configure the CMS ezcontents 2.0rc3. I had
previouse installed ezcontents 1.44 on an e-smith 5.5 with no problems at
all.

In this case several database creation files in the /sql directory, such as
MySQL_ezcontents_200_rc1_rc2_rc3_upgrade.php (I am listing the filename from
memory, so it may not be exactly correct, but its close) would not transfer.

Shortening the filenames made them move but crippled the installation.

I know I can untar the files directly on the e-smith machine, its just
easier to do remotely. So if there is a way to accomplish this without
having incorrectly named files, or this transfer problem, it would be a
pleasure to know it.

Thanks for any enlightenment, and please let me know (prefereably without
the sarcasm) if more information is needed.

[Michael Smith]

You don't think it was important that you're using Mac OS X?  You could've saved one round of back-and-forth by being more specific.  

Are you using Netatalk?  I can tell you from experience that Netatalk isn't really truly OS X friendly -- YMMV even between different releases, as you've found out -- and you'll probably get better results by disabling Netatalk on your SME Server and doing your fileshares via SAMBA on the OS X box.  Give that a try and let us know what happens.

But first, go to the mirrors and apply ALL the updates to beta 3 ... I note specifically that there's a netatalk RPM in there.  Here's a location:

http://www.ibiblio.org/pub/linux/distributions/e-smith/dev/6.0dev/updates/6.0beta3/RPMS/

Of course, you may have found yourself an actual bug, which you should report to Mitel.

Sarcasm?  No charge, all part of the service.

[Robert]

Assuming you were indeed transferring files through afpd, these snippets from the afpd man page may interest you:
"Unix files beginning with .' are not accessible from the mac." "Unix filenames that are longer than 31 characters are inaccessible from the Macintosh." These restrictions seem to be inherent to AFP 2, for which afpd provides an implementation. In other words, the problem is in the protocol, not the implementation. Supposedly AFP 3 allows for longer filenames, but there is no ETA for AFP 3 support in netatalk. You are better off using a different filing protocol. Or you can work on your SME server through ssh.
Could you provide more info on the case problem you had?