Comments 78
Проблема была решена запретом синхронизации невалидных UTF-16.

А есть ли какое-то еще решение кроме исключения невалидных суррогатных пар? Я сталкиваюсь с такой проблемой при парсинге сайтов и также ничего лучше кроме исключения таких пар не придумал.
Все зависит от того, реально ли вам нужно преобразование в кодировку, отличную от UTF-16. Я бы советовал работать именно с ней и оставить данное название «как есть». В другом случае, опишите ваш кейс более подробно, подумаем все вместе =)
Интересно, существуют ли какие-то утилиты, которые могли бы прошерстить содержимое диска и вывести список файлов, чьи имена содержат невалидный UTF-16?

Одна и та же директория синхронизируется с вендой, у которой UTF-16, и с линуксом, у которого UTF-8. Оставлять как есть и пусть в одной из систем будут крякозяблы вместо имён файлов?

Учитывается ли случаи, когда в папку синхронизации подмонтирована подпапка в какой-нибудь другой файловой системе? Ведь в таком случае ваш тест может не соответствовать действительности
Если в дереве появится какой-то номер inode, совпадающий с уже существующим, то пытаться обработать перемещение для этих файлов или папок мы не будем.
Также при обнаружения inode в другом месте проверяется контрольная сумма объекта (или какой-то процент соответствия вложенного контента, если это папка), которая отметает возможность ложного срабатывания.
C:\test>mkdir a.
C:\test>dir
 Volume in drive C has no label.
 Directory of C:\test
10.08.2016  15:41    <DIR>          .
10.08.2016  15:41    <DIR>          ..
10.08.2016  15:41    <DIR>          a.
               0 File(s)              0 bytes
               3 Dir(s)      39 964 672 bytes free

C:\test>cd a.
C:\test\a.>


Хм… Я не припоминаю, чтобы я что-либо патчил. Попробую проверить на других системах.
что значит тоже — я ж привел пример, что у меня на win7 64бит все отлично сработало и в cmd и в FAR.
Дополнение к
Попробую проверить на других системах.

«тоже» = «так же, как и у остальных, а не как в вашей системе». В FAR все работает нормально.
Супер, оно, спасибо)
Windows 10 кстати тоже не может открыть такую папку.
mkdir \\?\C:\a.
echo test > \\?\C:\a.\1.txt
type \\?\C:\a.\1.txt

Посмотреть листинг директории не получится. Удалить отдельный файл тоже, только папку целиком: rmdir /S \\?\C:\a.\
FAR спокойно заходит в такие папки и позволяет работать с ними, как с обычными.
Можно создать из под виртуальной машины, в общей папке. Допустим, у меня ubuntu крутится на virtual box в windows 10. Из под убунты — папка отлично создаётся и работается с ней как ни в чём не бывало. Из под windows — эту папку видно, но никаких действий предпринять не получается, даже удалить не даёт.
«Мы полагаем, что их номера при переименовании файла не изменяются.»
При переименовывании inode и не будет меняться. А при редактировании — может. Если данные не меняются — inode не меняется. Все зависит от того, с чем вы работаете — с directory entry или содержимым файла. У вас проблемы были только при изменении содержимого файла.

в Windows можно отключить создание короткого алиаса через реестр

В имени могут быть точки, но расширение — это отдельная структура, и с ней связаны ассоциации.
Следовательно если в конце точка есть а расширения нет, нельзя понять с чем оно ассоциируется. Поэтому файл и открыть нельзя.
А с каталогами да, забавно, но это баг именно проводника. Все остальное работает ОК.
в простых случаях номер иноды не меняется, но на самом деле это зависит от файловой системы. в некоторых случаях инода может поменяться. например — Lustre с clustered metadata.
«Следите за новостями» — это становится фирменым ответом на вопрос о вебдав.
Прошу инсайда: хотя бы в этом столетии ждать? или завещать детям/внукам?
Уверен, что как только выкатят webdav — сразу же отберут халявный террабайт

приставка "тера" (вообще-то 1012, а иногда терабайтом называют 240) — одна "р"


"терра" (от латинского "terra") — "Земля", две "р"

Я вот как-то раз создал файл с пробелом в конце. Удалять nodejs-ом пришлось.

пробел экранируется бэкслешом. Плюс автодополнение отлично это делает за вас

А как разруливается ситуация, когда валидное имя в одной fs синхронизируется на другую? К примеру, если на OS X юзер создал папку или файл con, то как этот файл/папка будет синхронизироваться на Windows?

Сейчас в разработке на находится инструмент, который позволит синхронизировать любые символы и названия. Неразрешенные для платформы символы будут экранироваться.
Буквально на днях разбирал интесный баг: оказалось, что у некоторых файлов в Облаке дата съехала далеко в будущее, вылетев за пределы int32. Скриншот того, как это выглядит в браузере есть по ссылке; что стало причиной глюка установить уже не получится — это могла быть как ошибка сохранения файла, ошибка в клиенте под Android, ну или ещё что-то.
Напишите мне на почту a.skogorev@corp.mail.ru, пожалуйста, подробную информацию о вашей проблеме, будем разбираться.
Скажите, а под Windows не было проблем с файлами начинающимися с пробела?
А когда уберете ограничение на максимальную длину пути/имени файла/имени папки?
очень странная идея ориентироваться на номера инодов. очевидное решение — строить свой namespace, а fs использовать как object storage. не?
Могли бы вы более подробно рассказать про технологию, поделиться какими-то ссылками?
кхм… ну вот так сразу ссылок нет. идея-то простая. представим, что каждый раз, когда Вы создаете новый объект (файл/каталог), вы генерируется уникальный ID — это будет эквивалент номера иноды. теперь этот уникальный ID используем как имя файла на локальной FS (ext4, например). таким образом получается «объектное хранилище» — плоское пространство объектов с ID, который генерируете Вы. дальше поверх этих объектов можно построить свое пространство имен: одни объекты хранят списки других объектов — каталоги.
предполагаемая засада — отстутствие атомарности: создание файла в Вашем пространстве имен будет распадаться на 2+ разные транзакции в локальной fs: создание объекта и запись о нем в Вашем каталоге. но в принципе и с этим можно справиться.

Вот я слегка не доверяю облакам и дополнительно шифрую всё, что туда кладу.


Существует замечательная схема: я внутри синхронизируемого дерева разместил том encfs. Это директория, которая содержит файл .encfs6.xml и файлы/директории с зашифрованными именами и данными. Имена получаются вида "QDtj2N,ncNwY2DeP38Ug-oR4", запятые и минусы могут быть где угодно (например, минус в начале имени или две запятых в конце — легко), это просто "модифицированный base64", в котором запятая и минус используется вместо слеша и плюса. Преимущество такой схемы в том, что я меняю один файл, он один и синхронизируется, а не весь том, как это было бы в случае с TrueCrypt.
А дальше я просто монтирую это в какую-то директорию вне синхонизируемого дерева, и получаю прозрачно доступ к зашифрованным файлам.


Схема идеально работает в Dropbox, но вызвала проблемы в Cloud@Mail.ru. В какой-то момент ломается синхронизация, причём какой именно файл это вызывает — выяснить не удалось. В общем, это привело к тому, что mail.ru я теперь используют как вне-домовой бекап и работаю с ним только через веб-интерфейс.


Однако, хотелось бы работать по-нормальному!

Что значит «ломается синхронизация»? Могли вы написать мне на почту a.skogorev@corp.mail.ru дату проблемы, название проблемного файла, попробуем разобраться с вашей ситуацией.

Ну, прочитали вы не внимательно. Я же написал, что имя проблемного файла выяснить не удалось.


Я должен отметить, что это не единственная причина моего недовольства десктопным приложением. Другая, не менее важная — оно не работает без X. Мне это неудобно. Более того, оно теперь требует Qt5, что само по себе не плохо, но вот нет его на этом компьютере, так что даже просто запустить приложение не смог, а соберу потом, после отпуска. Дома собрано, попробую вечером, если не забуду.


Да, и ещё тонкость. Вот я использую Gentoo, я вполне допускаю, что вы не слышали, что кроме Debian (Ubuntu, Mint), Fedora и openSUSE конкретных версий существуют другие дистрибутивы, но у вас нет и элементарно "отвязанного от дистрибутива" файла .tar.gz (.bz2, .xz на выбор). Стыдно, даже богомерзкий Oracle выкладывает JRE и JVM в таком виде! (Ubuntu у вас тоже только древний)

нет и элементарно "отвязанного от дистрибутива" файла .tar.gz (.bz2, .xz на выбор).

Да ладно, мейнтейнеры других дистрибутивов могут использовать «привязанные к дистрибутиву» пакеты ровно как и .tar.gz: распаковка, применение специфичных для дистрибутива изменений, и, собственно, упаковка в целевой пакет. Если нет нужды во втором этапе, то есть конвертеры вроде debtap.

Если что, deb вообще руками распаковать можно. Ну, не совсем руками, это архив ar, внутри которого несколько сжатых архивов tar.gz и контроль-файлик. Но всё равно выглядит некрасиво.

Аналогично, пробовал использовать шифрованный sparse bundle (растущий пакет-образ диска) в OS X (пакет из файлов по несколько Мб, при изменении контента в образе меняются лишь соответствующие файлы). Всё ок, если работать с закрытым приложением облака, но на живую обязательно полезут коллизии синхронизации и конфликты файлов частей образа, что ломает весь образ в дальнейшем. В своё время писал достаточно детальный репорт, ответа не получил.
> И, вроде бы, все логично: если есть удаление, значит файла уже нет
Почему это? Это логично только для Windows. Для Линукс файл после удаления не виден, но удаляется только после того, как его закроет последняя открывшая/создавшая его программа. Использовал активно для работы с временными файлами. Очень удобно. Даже если крешится программа, то все временные файлы уже при создании удалены и не засоряют систему
Да, это POSIX фича.

Файл жив, пока на него есть хотя бы одна ссылка, а в Linux имя файла — это именно ссылка на конкретный inode.

При открытии файла, на него создается очередная ссылка среди прочих открытых дескрипторов где-то в /proc/PID/fd — она и держит файл от удаления.

Поэтому в Linux могут быть полноправные несколько имен на тот же файл, и открытый в каком-то процессе файл — такая же ссылка, включая то, что у нее есть обычный файловый путь.

Эта философия, например, позволяет сделать автоапдейт программы, не создавая отдельный «апдейтер», а заменяя файл прямо там где он есть, да и вообще много забавных вещей.
Хотел проверить это приложение и поковырять с разными файлами, в итоге не запускается, а в консоли ошибка сегментации.
Пожалуйста, отправьте мне на почту a.skogorev@corp.mail.ru вашу версию ОС и дамп файл, если есть, будем разбираться.
Да ну о чём вы? Если элементарные мета-данные вроде времени создания файла не хранятся, какие тут потоки…
И чисто для интереса — а вы такие вещи, как стримы, существующие для файлов и директорий в NTFS — синхронизируете?
Альясы всегда в высоком регистре, содержат знак "~", за которым идет цифра, увеличивающаяся, если такой альяс уже занят (Например: «C:\PROGRA~1\»)
Не совсем верно. Не знаю, как сейчас в 8-ках и прочих, но в 95, 98, ХР тильду можно отключить через реестр, что я и делал. Из эстетических соображений и из практических. Иногда проще искать файл, если имя чуть длиннее (в куче файлов с похожими именами). Сейчас уже не актуально, но тем не менее.
Можно вообще отключить эти короткие имена в современных операционных системах.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"NtfsDisable8dot3NameCreation"=dword:00000001


Либо через групповые политики (Конфигурация компьютера → Административные шаблоны → Система → Файловая система → NTFS → Параметры создания коротких имён).

Всегда первым делом отключаю короткие имена. За 10 лет встретилась лишь одна программа, установщик которой из-за этого вываливался с ошибкой — какая-то древняя версия CSE HTML Validator.
Решение отключить что-то в реестре должен принимать пользователь, а не мы =)
Мы учимся работать с тем, что есть.
Так и речь о том, что это может быть потому, что пользователь такое решение принял.
Как решаете кроссплатформенные ограничения? Например, на линуксе создали файл с двоеточиями и звёзодчками в имени, что получится, если такой файл синхронизировать на Windows? И наоборот, если в Windows создать файл с именем в 250 русских символов, что получится на линуксе (у Ext4 ограничение в 255 байт, русские буквы занимают в UTF-8 по два байта, так что не влезет)?
По запрещённым символам да, это я проглядел. Но что делать со слишком длинными именами, тем более, если префикс допустимой длины будет совпадать? Как в DOS будете сокращать и дописывать ~1, ~2 и.т.д.? Тогда надо будет вести какой-то реестр соответствия имён, наверно.
А что сейчас с длительностью индексирования всех файлов? Я как-то пытался подключить к облаку свои каталоги, но индексирование занимает ну очень много времени, причем из-за высокой нагрузки на диск практически невозможно пользоваться никакими программами. К тому же, в какой-то момент, у меня просто перестали индексироваться файлы (приложение ходит по кругу и пытается проиндексировать одни и те же каталоги, видимо, в какой-то момент ломается и начинает это делать заново)
Мы прямо сейчас работаем в направлении ускорения индексации.
Можете написать мне на почту a.skogorev@corp.mail.ru, посмотрим, чем вызвана конкретно ваша проблема.
Спасибо за интересную статью. Несколько вопросов.
Используете ли при блочную синхронизацию или синхронизация на уровне файлов? Какие хэши для файлов используете, попадались ли коллизии?
В вашем облаке очень не хватает поддержки журнала версий файлов как в DropBox. Планируется ли введение данного функционала в ваше облако?
Забавная штука, в проводнике (семёрка) создать папку с точкой просто не получается, а если попробовать создать с двумя точками, то она вообще исчезает из перечня. Появляется, если нажать F5, ессно, уже без точек
Под macOS на FAT создаются новые файлы (не папки) с inode номер 9999…


inode и FAT????
Наверное просто stat команда на FAT и других не-POSIX файловых системах выводит 9999 для всех, вот и подумали…
например на NTFS портированный stat из git работает, в смысле пытается выдавать информацию, и номер inode и даже количество линков, правда на всех каталогах там только один линк, то есть что оно выдает — неясно. Владельца, размеры и timestamps выдает верно
А можно узнать, как вы работаете с файлами к примеру Microsoft Word? Он при сохранении файла, идёт в три шага —
1) Создает временный файл, куда сохраняет новую версию
2) Удаляет предыдущий файл (до редактирования)
3) Переименовывает темповый
При синхронизации на это либо надо ставить специальный хак именно на doc&docx (и ещё некоторые), либо синхронизировать полностью, даже если поменялся один символ. Сам сталкивался с этой проблемой, хотелось бы узнать как у вас её решили.
Есть ряд правил:
1) Мы не синхронизируем временные файлы офиса, информация об этом есть в статье
2) Мы начинаем синхронизацию через 4 секунды после изменения

Таким образом, файл будет изменен правильно.
А можно где-нибудь посмотреть список темповых файлов-путей которые вы не синхронизируете? :)
Only those users with full accounts are able to leave comments. Log in, please.