Многопользовательский доступ на чтение/запись к меткам

[seva100]

Сим линки не я предложил.

Симлинки были предложены в свете Ваших верхних слов: "скрипт или cmd, который перед запуском копирует с сервера эталоны файлов в профиль пользователя." То есть файлы sync'аются через профили и становятся локальными и отдельными у каждого пользователя, линкуй куда угодно в пределах его локальной системы - не хочу. Разумеется, САС при этом тоже должен быть локальным (для обеспечения монопольного доступа на запись к этим двум файлам) - т.е. у каждого свой. Вот оттуда, где САС лежит - и можно было залинковать на файлы, копируемые\приходящие через профиль, то есть в пределах одной локальной системы все будет работать, и изменения будут уходить на сервер через профиль.
Теперь же оказывается, что и вся программа пускается с сервера: "Программа SAS лежит на шаре сервера. Доступ к ней происходит через запуск ярлыка с корпоративного сайта". То есть, программа по сути одна, она не локальна, и файлы по сути одни - а к ним пытаются взять мультидоступ из программы, не подразумевающей таковой фичи. Ну-ну, блажен кто верует...
Либо я вообще не понимаю, что и как там у Вас. Скрипты "запуска с сервера через скрипт или cmd", конфигурации всего вопроса - в студию.

А теперь читаем мое первое сообщение:

Идя такова. В SASPlanet.ini указывам хранение sml файлов в профиле пользователя через системные переменные (например:Categorymarks=%userprofile%\Categorymarks.sml)
На сервере я храню эталоны этих файлов. Программа запускается с сервера...

В конце страницы оказывается, что самый активный отвечающий не внимательно прочитал вопрос. Бывает.
Дабы не утомлять будующих читателей этой ветки форума предлагаю модераторам почистить мою переписку с Parasite.
Чем разбираться с витееватостью недопонимания опишу подробней о чем мечтаю.

Итак задача.
Локальная сеть. Клиенты XP. Сервер 2003 (или 2008. не важно). На шаре сервера установлен SAS. Пользователи запускают SAS посредством тыкания в ярлык расположенном на корпоративном сайте.
Работа с метками: Админ может все. Юзеры только просмотр, но с возможностью выбора групп и меток для отображения.

В настоящий момент решение заключается в следующем.
SAS размещается (например скриптом) локально, в профиле каждого профиля. Кэш на сервере. Ярлык запуска на шаре сервера или корпоративном сайте. Ярлык запускает скрипт, который копирует поверх файлы sml c сервера в локальную папку SAS. И потом скрипт запускает сам SAS. (Таким образом перед каждым запуском SAS происходит восстановление sml файлов до эталонных)
Минусы. Увеличивается время запуска SAS. При запуске скрипта, необходимо проверить наличие SAS в локальном профиле, проверить версию, при необходимости обновить/скопировать SAS. И только потом сам запуск.

Решение которое хочется увидеть.
SAS лежит и запускается с шары сервера, например через ярлык с корпоративного сайта.
В SASPlanet.ini через переменные Categorymarks.sml и marks.sml указывается полные путь к этим файлам. (Например: marks.sml="%userprofile%\sas\marks.sml") (SAS должен научиться использовать системные переменные).
Таким образом, для многопользовательского доступа к метка в режиме чтения, мне достаточно cmd`шкой сперва переписать поверх файлы sml в профилях, а потом стартовать прогамму

[zed]

Решение которое хочется увидеть.

Хотелки пишите в багтрекер.

[Parasite]

SAS лежит и запускается с шары сервера, например через ярлык с корпоративного сайта.
В SASPlanet.ini через переменные Categorymarks.sml и marks.sml указывается полные путь к этим файлам. (Например: marks.sml="%userprofile%\sas\marks.sml") (SAS должен научиться использовать системные переменные).
Таким образом, для многопользовательского доступа к метка в режиме чтения, мне достаточно cmd`шкой сперва переписать поверх файлы sml в профилях, а потом стартовать прогамму

Повторяю ответ: все это делается стандартными функциями системы (системы, повторяю - доработка САСа не нужна) прямо сегодня, и одна копия САСа (программы, даже теоретически не знающей про мультипользование) для всех юзеров не есть правильный подход изначально. Опять же, налицо явное недопонимание функций профиля и шары - то, что можно\нужно делать через первое, почему-то упорно натягивается на второе...впрочем, понятно.

Итак, варианты решения вопроса. Доработка САСа на тему возможности указания расположения файлов sml не нужна, потому что:

1. Вся папка САСа (вместе с включенными sml) вполне безболезненно перемещается в пределах системы, отдельные же файлы из ее состава вполне безболезненно перемещаются через симлинки;

2. Можно (в Вашем случае) по событию входа юзера в домен (userinit/logon script) класть ему в профиль нужные sml, которые придут ему на машину в штатном порядке sync'ания профиля. Придя к нему на машину - они будут ему доступны и на чтение, и на удаление, и на запись - не вызывая никаких AV и прочих Sharing violations. САС при этом у каждого юзера, разумеется, должен быть свой (и в его папках должны быть симлинки на туда, куда приходят sml в профиле). При выходе юзера - обновленные им sml закинутся на сервер, но это никого не будет волновать потому что при следующем его входе они перезапишутся оригинальными - чем достигается "якобы R/O".

3. Если охота возможности полностью иметь под контролем весь САС на стороне юзверей, изменять им инишник, обновлять программу - то то же самое что и выше, но уже не только уже ко всей папке САСа а не к файлам sml. Симлинки на стороне пользователя в этом случае уже не нужны - ему приходит полностью работоспособный пакет, можно даже организовать каждому свой собственный workaround. Проверки апдейтов и прочая лабуда админом разово для всех или отдельно каждому - по желанию, при входе юзера в домен - у него будет свой собственный готовый пакет, засим все.

4. Если нужно не только R/O, а нормальный R/W - то то же самое что и выше, только файлы логонскриптом не перезаписываются, а сперва парсятся на стороне сервера (изменения\добавления кидаются в локальную БД там же), тут же из БД генерируется новый полный свежий sml со всеми нужными записями - кой и кладется юзеру в профиль, далее см.п.2. Опять же, всё это весьма прозрачно для пользователя - он вошел в домен, у него есть рабочий САС, засим всё.

Заметьте, никаких писаных на коленке невнятных "ярлык запускает скрипт на корпоративном сайте", никаких "SAS должен научиться использовать системные переменные", и даже шары нигде не используются. В общем и целом, юзерам с их ярлыками\кликаниями\польз.скриптами вообще нечего делать на домен-контроллере организации, ибо это весьма плохая политика и весьма убогий подход к делу, плюс чреватый дырками чуть менее чем весь. Задачи сервера должны делаться на сервере, и чем меньше actions дается стороне хомяка - тем лучше для всех оставшихся (в идеале - терминальная работа, как самая безопасная и надежная на сег.день).
Читайте предыдущие ответы и не плодите флуд, если не знаете свою же администрируемую систему.

PS: особо же порадовал "ярлык, расположенный на корп.сайте". Дожились.....

[vdemidov]

На самом деле все это обсуждение в данном разделе форума оффтопик и флуд. Это раздел для тех кто хочет помочь в разработке. Все остальные идут в другие ветки и в багтрекер.

[Parasite]

На самом деле все это обсуждение в данном разделе форума оффтопик и флуд. Это раздел для тех кто хочет помочь в разработке. Все остальные идут в другие ветки и в багтрекер.

Кстати, да. Вся эта ветка с первой мессаги не особо направлена на именно разработку САСа. Может, есть смысл всю её перенести в общий раздел?

[Tikh]

Итак, варианты решения вопроса. Доработка САСа на тему возможности указания расположения файлов sml не нужна, потому что:

1. Вся папка САСа (вместе с включенными sml) вполне безболезненно перемещается в пределах системы, отдельные же файлы из ее состава вполне безболезненно перемещаются через симлинки;
2. Можно (в Вашем случае) по событию входа юзера в домен (userinit/logon script) класть ему в профиль нужные sml, которые придут ему на машину в штатном порядке sync'ания профиля. Придя к нему на машину - они будут ему доступны и на чтение, и на удаление, и на запись - не вызывая никаких AV и прочих Sharing violations. САС при этом у каждого юзера, разумеется, должен быть свой (и в его папках должны быть симлинки на туда, куда приходят sml в профиле). При выходе юзера - обновленные им sml закинутся на сервер, но это никого не будет волновать потому что при следующем его входе они перезапишутся оригинальными - чем достигается "якобы R/O".
4. Если нужно не только R/O, а нормальный R/W - то то же самое что и выше, только файлы логонскриптом не перезаписываются, а сперва парсятся на стороне сервера (изменения\добавления кидаются в локальную БД там же), тут же из БД генерируется новый полный свежий sml со всеми нужными записями - кой и кладется юзеру в профиль, далее см.п.2. Опять же, всё это весьма прозрачно для пользователя - он вошел в домен, у него есть рабочий САС, засим всё.

Доработка САСа на тему возможности указания расположения файлов sml - нужна.
Я хочу организовать так, что SAS у клиентов, sml - на сервере в локальной сети.

Костыльность такого способа осознаю, но мне не под силу городить доменные политики, скрипты, и БД. И локалкой с доменом рулю совсем не я, да и гемор нехилый. А решение с указанием пути к файлам меток меня полностью устроит.

На клиентских машинах ХР, где симлинков нет.

Давно создал в Багтрекере инцидент-хотелку по этому поводу: http://sasgis.org/mantis/view.php?id=173

[Parasite]

Я хочу организовать так, что SAS у клиентов, sml - на сервере в локальной сети.Костыльность такого способа осознаю, но мне не под силу городить доменные политики, скрипты, и БД. И локалкой с доменом рулю совсем не я, да и гемор нехилый. А решение с указанием пути к файлам меток меня полностью устроит.

Ммда. Опять - двадцать пять...

Вас устроит теоретическое решение. То есть - исполнение Вашей личной хотелки чьими-то чужими силами и личным временем.
А практическое (то есть - реальные вещи) - уже нет. Было бы совершеннейшей глупостью думать, что любая кухарка может управлять государством помещение пары файлов на общую RW шару может решить проблемы с мультидоступом. Да Ха-Ха Вам 3 раза, уважаемый! Вот смотрите:
1. Файлы лежат на удаленной шаре. ОК.
2. Запускаем САСа на клиенте н.1. Клиент1 ломится на шару, говорит - "Ой, а вот мои файлы!!" - открывает их на R\W (чтение\запись), и держит их так под исключительно свои нужды.
3. Запускаем САСа на клиенте н.2. Клиент2 ломится на шару, говорит - "Ой, а вот мои файлы!!...но их кто-то не дает открыть на R\W, так как они уже кем-то держатся - а кем я понятия не имею, так как SMB-протокол не подразумевает передачи владельца\пользоватея...Посему на тебе, юзер, пока что еррор Sharing Violation - и устраняй проблему сам, а я пока подожду..."
4. Помножить на число юзеров.

5. А уж что может быть когда юзер_1 удаляет метку, а юзер_2 ее же редактирует в то же время- уже описано выше.

Давно создал в Багтрекере инцидент-хотелку по этому поводу: http://sasgis.org/mantis/view.php?id=173

Вы забыли дописать туда волшебное слово "мультидоступ". Положить же нужние файлы в сеть можно хоть сейчас - subst Вам в помощь.

PS: именно поэтому в мире и придуманы базы данных - которые держат хранилища данных открытыми в одно рыло, а все желающие (через очередь) спрашивают данных не у файлов, а у того кто держит это самое хранилище. Слова "смотреть куда-то в сторону баз данных" Вы тоже можете найти выше. Плюс, оно есть и в FAQе.

PPS: И в XP есть линки. Они есть в винде начиная с NT4 - а это, пардонэ муа, 1996й год. Ссылку выше я для кого дал?

[Tikh]

Я хочу организовать так, что SAS у клиентов, sml - на сервере в локальной сети.Костыльность такого способа осознаю, но мне не под силу городить доменные политики, скрипты, и БД. И локалкой с доменом рулю совсем не я, да и гемор нехилый. А решение с указанием пути к файлам меток меня полностью устроит.

Ммда. Опять - двадцать пять...

Вас устроит теоретическое решение. То есть - исполнение Вашей личной хотелки чьими-то чужими силами и личным временем.
А практическое (то есть - реальные вещи) - уже нет. Было бы совершеннейшей глупостью думать, что любая кухарка может управлять государством помещение пары файлов на общую RW шару может решить проблемы с мультидоступом. Да Ха-Ха Вам 3 раза, уважаемый! Вот смотрите:
1. Файлы лежат на удаленной шаре. ОК.
2. Запускаем САСа на клиенте н.1. Клиент1 ломится на шару, говорит - "Ой, а вот мои файлы!!" - открывает их на R\W (чтение\запись), и держит их так под исключительно свои нужды.
3. Запускаем САСа на клиенте н.2. Клиент2 ломится на шару, говорит - "Ой, а вот мои файлы!!...но их кто-то не дает открыть на R\W, так как они уже кем-то держатся - а кем я понятия не имею, так как SMB-протокол не подразумевает передачи владельца\пользоватея...Посему на тебе, юзер, пока что еррор Sharing Violation - и устраняй проблему сам, а я пока подожду..."
4. Помножить на число юзеров.
5. А уж что может быть когда юзер_1 удаляет метку, а юзер_2 ее же редактирует в то же время- уже описано выше.

Я же написал: "Костыльность такого способа осознаю... решение с указанием пути к файлам меток меня полностью устроит." Использую САС в локалке более года и знаю про все эти подводные камни. Но сейчас - приходится хранить в шаре всю программу целиком, что ещё хуже, чем решение, которое запрашивается мной и другими.

Давно создал в Багтрекере инцидент-хотелку по этому поводу: http://sasgis.org/mantis/view.php?id=173

Вы забыли дописать туда волшебное слово "мультидоступ". Положить же нужние файлы в сеть можно хоть сейчас - subst Вам в помощь.

PPS: И в XP есть линки. Они есть в винде начиная с NT4 - а это, пардонэ муа, 1996й год.
Ссылку выше я для кого дал?

Вы сами эту ссылку читали? Цитирую: "Создавать жесткие связи можно только на том же диске, на котором расположен исходный файл.". Как это поможет в нашем случае? Симлинков на файлы в ХР нет, а хардлинки и директори-джункшны неприменимы. Subst - не переносит программу на локальный компьютер, это будет тот же самый запуск из сети. А хотелось бы - запуска программы на локальном компе, но файлы меток хранить на сервере.

[Parasite]

приходится хранить в шаре всю программу целиком, что ещё хуже

Чем конкретно хуже, и что конкретно изменится если там будут лежать только sml (см.ниже, красными буквами)?

Вы сами эту ссылку читали? Цитирую: "Создавать жесткие связи можно только на том же диске, на котором расположен исходный файл.". Как это поможет в нашем случае?

А разве одной моей ссылкой весь интернет ограничился? Я ее за полминуты нагуглил. Вы не поверите, но есть КУЧА и других ссылок по теме, как и множество решений Вашего случая (например в никсах элементарно можно прицепить удаленную шару как папку легким движением консоли - через банальный mount, и даже симлинки не понадобятся).
Кстати, что конкретно есть "Ваш случай"? Я не вижу ни описания вопроса, ни конкретной конфигурации - ничего. Одно невнятное "Я хочу!". Как и от предыдущего оратора тоже (и на прямой вопрос - ответа не было).

Симлинков на файлы в ХР нет, а хардлинки и директори-джункшны неприменимы. Subst - не переносит программу на локальный компьютер, это будет тот же самый запуск из сети. А хотелось бы - запуска программы на локальном компе, но файлы меток хранить на сервере.

Тогда гуглим на "Создание точек соединения DFS" (оно работает в сети, а "точки соединения NTFS" - на дисках). Например, вот.
Простой вынос файлов на общую шару вопроса с мультипользованием не решит - а проблем таки добавит. Для тех, до кого это утверждение все еще кажется спорным - могу предложить запустить две копии САСа из одной локальной папки (в этом случае они оба будут брать единые sml) и попытаться вменяемо поработать с метками сразу в обоих. Только забэкапить их не забудьте...

PS: сколько можно обсуждать хотелку (причем не требующую доработки САСа!) в разделе "Для разработчиков"?

[Tikh]

приходится хранить в шаре всю программу целиком, что ещё хуже

Чем конкретно хуже, и что конкретно изменится если там будут лежать только sml (см.ниже, красными буквами)?

Хуже тем, что, насколько я понимаю, тормознее.

Вообще, если Вы горите, что нужно НОРМАЛЬНОЕ решение, то - для нормального решения я жду реализацию в программе поддержки плагинов.
Тогда можно будет написать для работы с метками свой плагин, который бы работал с MySQL.
Ну или я ещё предлагал как-то другое решение: метки хранить в программе иным методом, где: папка - категория, подпапка - подкатегория, файл - метка. Один файл - одна метка.

Простой вынос файлов на общую шару вопроса с мультипользованием не решит - а проблем таки добавит.

Худо-бедно решает вот уже более года как. С проблемами - норм.