Victor Glembitsky

Асус как-то добротнее выглядит что ли… Три внешних антенны, съемные. При недостаточном уровне сигнала можно будет заменить. 2 юсб входа у него — в один внешний жестяк, в другой принтер. Ну и по цене он вроде выигрывает. У самого классика жанра wl500gp2. Если и буду менять, то только на Асус.

Озвучьте свою предполагаемую зарплату на новом месте, +20%, какие проблемы?
Либо работодатель согласится ( вам плюс ), либо будет торговаться, а у вас есть 20% запаса

Наверное потому что 1С-ники не пишут сюда статьи.

Когда я на собеседование ходил, мы про аниме говорили… Взяли.

Атрибуты фала — вотчина файловой системы. Это раз.
Второе — Почти все DLP системы умеют мониторить объекты ФС и ведут историю состояний этих объектов. Если DLP сертифицирована — доказательство у вас есть на основании журнала изменений объекта. То же самое касается и вопроса о копиях файла. Первая копия = оригинал. С него начался отсчет версий — остальные = копии.
Но хочу заметить, что все это происходит без отрыва от ФС. Без фаловой системы, сам файл — информация, которая, чисто логически, не имеет ни каких атрибутов (возраста, цвета, темы, назначения, владельца и т.д.), эти атрибуты появляются тольок в рамках чего-то. Поэтому «привязка на местности» обязательна.

Никак. При помощи той же touch можно нехитро поменять дату.

Любая временная метка упирается в достоверность часов по которой она сделана. Как определить что системные часы не были переведены?
Я лично приму только свидетельство третьей независимой стороны — вложение в мейл или архив.

Совпадение с версией файла сохраненной на внешнем незаинтересованном и доверенном источнике.
Например вложение в письмо на гмейле с отметкой о дате получения сервером.

Журналируемая ФС, каждый элемент журнала подписывается цифровой подписью пользователя. Так можно исключить подделку времени третьими лицами. Чтобы исключить подделку времени самим пользователем, отправлять хеш файла на сервер, который будет удостоверять модификацию файла своей подписью: «ID системы такой-то, файл такой-то, хэш изменений (или хэши файла до/после) такой-то, дата, время, цифровая подпись».

Без привлечения третьей стороны и использования физических методов (радиоактивные метки, саморазмагничивающиеся HDD...) — боюсь, что никак.

Задним числом, по уже существующим файлам — точно никак.

По большому счету, без цифровой подписи — никак.

Ну если ежедневно логи со списком файлов и их данными будут записываться на dvd-r, думаю это можно считать неплохим доказательством. Только если известно, что заранее никто не знал, какой именно файл и когда заинтересует следствие, и не менял у него дату специально для логов или в самих логах.

Если пофантазировать, то при записи намагничивается определенный сектор, со временем он естественно немного размагничивается, как-нибудь замерить текущее намагничивание сектора и прикинуть сколько времени прошло с момента записи.

Кажется мне, что это что-то из разряда неразрешимых задач. Как, например, доказать что данный файл «оригинал», а не «копия»? :-)

хм, пойду ка я бэкап сделаю…
спс за новость

www.jam-software.com/freeware/

Пропасть. :)

База спроектирована нормально, гораздо хуже было бы с таблицей вида (деталь, магаз1, магаз2, магаз3).
Попробуйте группировку, например так:

select номер_детали, group_concat(номер_магазина) as мазагины from детали group by номер_детали

entityId_1 | entityId_2
это не плохо спроектированная связь, а вполне себе 'многое ко многому'.

Ваш вопрос очень плохо сформулирован.
Что-то вроде:

Привет, у нас есть функция для работы с юникодом, а данные по количеству покупок хранятся в redis. Как лучше всего сделать голосовалку для пользователя?

www.phpclasses.org/