Вы прошли такой длинный путь без длинных имен файлов, и, вероятно, вам следует еще немного подождать с их использованием.
Дэвид Берлинд
Сейчас, когда Microsoft выпустила Windows 95, некоторые скажут, что они достигли своей цели на пути к длинным именам файлов (LFN - Long File Names). В настоящее время последние версии всех операционных систем для настольных компьютеров - Windows, Mac, OS/2 и Unix поддерживают LFN.
Но просто потому что у вас теперь есть LFN, решение воспользоваться их преимуществами независимо от операционной системы, используемой вашей организацией, - совершенно другой вопрос.
По сравнению со старыми ограничениями "восемь-точка-три" в DOS длинные имена дают ощущение свободы. Хотя конечные пользователи, наверное, оценят освобождение от оков соглашений об именах в DOS, менеджерам информационных отделов (IT) следует учитывать последствия разрешения пользователям присваивать LFN своим файлам.
Я рекомендую установить политику, которая бы требовала от пользователей придерживаться в именах файлов наименьшего общего знаменателя, пока все: настольные операционные системы, файловые серверы и установленные приложения - не будет способно поддерживать длинные имена файлов одинаковым образом. Если один из упомянутых компонентов инфраструктуры вашей компании все еще требует более коротких имен файлов, использование LFN приведет только к путанице.
Например, хаос может возникнуть, если некоторые пользователи перейдут на Windows 95, продолжая работать с 16-разрядными приложениями, такими, как Notes корпорации Lotus Development. Большинство 16-разрядных приложений не поддерживает LFN. Следовательно, если вы присоедините файл с LFN к почтовому сообщению Notes, это имя, вероятно, будет преобразовано к формату 8.3.
ЧТО В ИМЕНИ?
То, что было осмысленным именем файла, может превратиться в полную чепуху. При выполнении соглашения 8.3 пользователи, по крайней мере, по привычке пытались давать файлам осмысленные, хотя и ограниченные названия.
Возьмите тот же файл с LFN, который вы только что пытались присоединить к сообщению в Notes, и попробуйте открыть его в 16-разрядном приложении. Затем попытайтесь скопировать файл на дисковый том NetWare, на котором не загружен NLM-модуль (NetWare Loadable Module) OS/2 Namespace и который поэтому не может поддерживать LFN.
Этот эксперимент показывает, что правила преобразования LFN в формат 8.3 неодинаковы в различных сетевых операционных системах (ОС), настольных ОС и приложениях.
В действительности вы должны попробовать провести всевозможные эксперименты. Разделяйте диски между Windows 95, Windows 3.х, OS/2 и Macintosh. Используйте разные комбинации операционных систем и приложений, чтобы посылать файлы с длинными именами пользователям на различных платформах. Копируйте эти файлы на файловые серверы.
Поскольку преобразования имен файлов часто определяются системой назначения, вы обнаружите, что все кончится тем, что разделяемые в рамках рабочей группы файлы будут скорее всего иметь бессмысленные и в некоторых случаях различные имена у разных пользователей. В зависимости от частоты, с которой ваши пользователи обмениваются документами, это может представлять серьезную проблему.
Что должен сделать менеджер IT? Попросите своих пользователей подождать. Не используйте длинные имена файлов, пока вся инфраструктура вашей организации не будет готова работать с ними одинаковым образом,
Кстати, один из способов справиться с LFN в 16-разрядных приложениях под Windows 95 - это использовать Name-It фирмы Vertisoft.
С Дэвидом Берлиндом можно связаться через MCI Mail по адресу: 488-6680 или через Internet по адресу: dberlind@pcweek.ziff.com.
ДЭВИД БЕРЛИНД
