dedup это такая фишка 2k12 серверов - deduplication, повторяющиеся куски у разных файлов хранятся в одном экземпляре в спрятанных файлах-контейнерах. у дедуплицированных файлов стоят 2 атрибута - reparse point и sparse....
проверил. ничего страшного не происходит - access denied и атрибут остаётся. хотя тоже лучше бы было не давать его менять.
2useven10 wrote:проверил. ничего страшного не происходит - access denied и атрибут остаётся. хотя тоже лучше бы было не давать его менять.
У меня тоже "access denied", но у меня и прав таких априори нет. Скорее всего, и никому на таких файлах не положено снимать атрибут (его сама система иногда снимает).
Есть ещё, кстати, DFS Root, для которого такая операция тоже бессмысленна и приводит к следующей ошибке:
LastError: 0x00000008 - Not enough storage is available to process this command.
John Doe wrote:Вообще сомнительная затея с этим флажком.
Согласен, очень неочевидно стало. Мне больше нравилось как раньше.
Программисты меня поймут - в классическом Unix в API есть два вызова для удаления ссылок/файлов: delete и unlink. Правда, там первая, кажется, удаляет target, поэтому чаще (в целях безопасности) используется вторая, так как она при отсутствии линков равносильна первой.
Хотя, может оно и к лучшему, чтобы не пугать обычных пользователей. Если бы снятие флажка было заблокировано в тех случаях, когда это бессмысленно, тогда можно и через флажок оставить.
имхо раньше было правильнее.
по крайней мере, на кнопке было написано, какое действие будет выполнено.
то что не все понимали, что там написано и что само действие может потребоваться раз в 10 лет,
это гораздо меньшее зло чем теперь - невинное (нечаянное) снятие флага приводит к тем же
вряд-ли осознанным последствиям, только с гораздо меньшей очевидностью.
ну и плюс недоделанность интерфейса - выставить флаг нельзя, снимать зачастую тоже...
Поддерживаю двумя руками и ногами за "вернуть старое поведение, показ кнопки разрыва линка сделать настраиваемым". Когда увидел, что в 3-й версии этого нет - был неприятно удивлён. Просто бесит, как неудобно, после того как привыкнешь. Хоть на предыдущую откатывайся.
Про наличие у папки/файла нестандартных прав доступа, альтернативных потоков и хардлинков, например - это совсем не из области фантастики, очень даже здорово. Особенно на работе, когда нужно пользователям жизнь "усложнить" .
1. Зарубежные гости взывают с 2010 года о сохранении хардлинков при копировании. Это будет, есть или не будет?
2. При замене получателя (F6), имеющего хардлинк, получатель обновится, а связь порвётся и хардлинк останется старым. Если же скопировать поверх с заменой (F5), то получатель обновится вместе с хардлинком. Так задумано или можете допилить F6, чтоб обновлялся и хардлинк?
Вовсе не факт, что это будет ожидаемое пользователями поведение. Жёсткая ссылка на то и есть жёсткая, что привязана не к записи в директории, а к контенту. При копировании с перезаписью переписывается именно контент, а при переносе в пределах раздела заменяется только запись в директории.