Как использовать программные ссылки для повторного использования, созданные на Mac в Windows 8

Ответ 1

В вашем вопросе отсутствует пара деталей, поэтому мне нужно будет догадаться о вашей ситуации. Проблема заключается в следующем:

Вы создали некоторые символические ссылки, используя OS X в файловой системе, и теперь вы возникают проблемы с доступом к этим символическим ссылкам в Windows.

Если вы не сделали что-то сложное, например, установить сторонние драйверы файловой системы, тогда единственная файловая система, которую Windows и OS X может читать и записывать, основана на FAT. Поэтому я предполагаю, что ваша ситуация такова:

Вы создали некоторые символические ссылки, используя OS X в файловой системе FAT32, и теперь у вас возникают проблемы с доступом к этим символическим ссылкам в Windows.

Предполагая вышеприведенную ситуацию, проблема в том, что в FAT32 нет символических ссылок, потому что файловая система их не поддерживает. OS X обманывает вас, потому что он "просто работает". Что действительно происходит, так это то, что OS X создает текстовый файл ASCII, содержащий строку "XSym" вместе с именем файла, к которому он привязан, плюс некоторые сведения о файловой системе. Вы можете подтвердить это, открыв свои программные ссылки в системе Windows в блокноте. Обычно вы видите двоичный код, если вы открываете фактическое изображение в блокноте, но вместо этого вы должны увидеть текст из этих поддельных символических ссылок.

Итак, что вы делаете? Я вижу пару вариантов:

• Вы можете использовать файловую систему, поддерживающую софт-ссылки. Это может означать использование HFS + (файловой системы OS X), которая потребует установки драйверов HFS + в вашей системе Windows, чтобы она могла читать/записывать в файловую систему. Или это может означать переход в другом направлении и использование NTFS (файловой системы Windows), которая потребует установки драйверов NTFS на вашем Mac. Обратите внимание, что самые последние версии OS X могут читать файловые системы NTFS, они просто не могут писать им.

• Вы можете использовать поддельные символические ссылки, которые создает OS X. Для этого потребуется написать парсер для интерпретации ссылок или поиска библиотеки, которая сделает это за вас. У меня нет копии, но я считаю, что формат XSym описан в книге "OS X Internals".

• Вы можете пересмотреть подход к своей проблеме, чтобы он не требовал использования символических ссылок.

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

== == EDIT

Взгляните на документацию subversion на символические ссылки здесь. Соответствующая цитата из документа:

Вершина символических ссылок

На платформах, отличных от Windows, Subversion поддерживает файлы версий специальная символьная ссылка (или символическая ссылка). Символьная ссылка - это файл, который выступает как своего рода прозрачная ссылка на какой-либо другой объект в файловая система, позволяющая программам читать и записывать эти объекты косвенно посредством выполнения операций с самой символической линией.

Когда символическая ссылка помещается в репозиторий Subversion, Subversion помнит, что файл был фактически символической ссылкой, а также объектом на что символическая ссылка "указывает". Когда эта символическая ссылка проверяется на другая рабочая копия в системе, отличной от Windows, Subversion восстанавливает реальную символическую ссылку на уровне файловой системы из версированной символической ссылки. Но что никоим образом не ограничивает удобство использования рабочих копий на таких как Windows, которые не поддерживают символические ссылки. В таких системах, Subversion просто создает обычный текстовый файл, содержимое которого является путь, на который указывает исходная символическая ссылка. Хотя этот файл не может использовать в качестве символической ссылки в системе Windows, это также не будет препятствовать Пользователи Windows могут выполнять другие связанные с Subversion деятельность.

В основном, он говорит что-то похожее на то, что я упоминал ранее, а это значит, что символические ссылки не поддерживаются, если это вообще происходит в системах Windows. Subversion просто создает текстовые файлы с содержимым ссылки, поэтому вы можете либо выяснить, как самостоятельно анализировать эти текстовые файлы, либо попытаться найти библиотеку, которая будет анализировать их для вас.

Ответ 2

Возможно, проблема в том, что в одном каталоге есть так много ссылок

Существует максимум 31 точка повторной обработки (и, следовательно, символические ссылки) разрешено в определенном пути.

См. также

• Вопросы программирования

Ответ 3

Я знаю, что я опаздываю в этом, но я надеюсь, что другие могут извлечь выгоду из моего ответа, даже если он может долго продолжаться.

Некоторый фон

Символическая семантика ссылок значительно отличается между системами unixoid и Windows. Как было сказано ранее, Windows использует точки повторной обработки для реализации символических ссылок и точек соединения (некоторые функции дедупликации в версиях сервера также, по-видимому, используют его).

Теперь точка повторной обработки содержит дополнительные данные в качестве подсказки для диспетчера ввода-вывода и диспетчера объектов. По существу, на основе тега точки повторной обработки (GUID) можно определить тип точки повторной обработки, а затем драйвер фильтра файловой системы обрабатывает детали. Вы можете найти умеренно подробное описание этого в 6-м выпуске "Windows Internals" в главе 9 или в недавнем наборе драйверов Windows или в MSDN под REPARSE_GUID_DATA_BUFFER (и смежные темы).

В unixoid системах метаданные файловой системы также содержат ключ, который (текстовый файл) является символической ссылкой. Если вы используете ls -l, этот ключ видится в виде ведущего l, например. в:

lrwxrwxrwx  1 user group         38 2015-10-12 11:51

Фактическое содержимое символических ссылок также зависит от системы, в Linux, например, они содержат только целевой путь.

То, что разделяют символические ссылки Windows и * nix, заключается в том, что цель не должна существовать во время создания. Также в Windows символическая ссылка может указывать на сетевое местоположение, которое является особенным, поскольку в сети Windows сетевые пути отличаются от локальных путей.

Возможная совместимость

Предполагая, что символическая ссылка была создана на стороне OSX или Linux, мы можем представить некоторые уровни совместимости. Если драйвер файловой системы на стороне Windows теперь будет представлять символические ссылки в качестве точек повторной обработки, а какая-то сторона (либо упомянутый драйвер файловой системы, либо фильтр файловой системы) будет обрабатывать эти точки повторной обработки, можно было бы интерпретировать целевой путь символической ссылки в в некотором роде.

Однако преобразование косых черт назад в обратную косую черту - наименьшее беспокойство.

В этом ответе Я уже изложил несколько случаев, когда невозможного значимого перевода невозможно.

По сути, единственный тип символических ссылок, для которых я вижу потенциальную совместимость, - это относительные символические ссылки. Но даже для них необходимо указать, что целевой путь не может указывать за пределами иерархии папок, которая видна на стороне Windows. То есть, если ваша символическая ссылка на стороне OSX или Linux находится внутри /var/www/html и указывает на ../../../something, это становится бессмысленным в случае, когда /var является установленным томом в Windows.

Если, однако, такая символическая ссылка /var/www/html/foobar и указана на ../html1/foo/bar, то вероятность того, что если /var был установленным томом на OSX или Linux, а теперь в Windows, относительный целевой путь все еще имеет смысл (после настроек, таких как вперед к обратным косам и т.д.).

Для любых абсолютных целевых путей драйвер файловой системы или драйвер фильтра файловой системы должен будет получить некоторые подсказки о том, как перевести исходную форму символической ссылки в целевую форму.

например. если символическая ссылка на /home/foo/bar часть /home может перевести на определенный установленный том.

Но вы уже можете видеть, что для этого требуется много вмешательства пользователя, поэтому, вероятно, большинство людей считают бесполезным даже попытку значимого перевода.

Возможное обходное решение для SVN

Возможным обходным путем для вас может быть использование внешних SVN. Это зависит от точного сценария, но поскольку вы используете SVN, они приходят на ум.

Вы можете рассматривать внешние SVN как родственные символические ссылки Subversion. Я использовал их таким образом, и я знаю нескольких других, которые имеют, но я не знаю, насколько распространен этот ход мысли и последующее использование.

Внимание: внешние ссылки, указывающие на файлы, были введены только в SVN 1.6, поэтому это может быть или не быть проблемой в вашем сценарии.

Внешние внешние элементы SVN представлены в нескольких вариантах. Вы можете установить их для папок или файлов (файлы только с 1.6 и более поздними). ​​

И внешний может указывать на:

• внешнее репо (schema://server/path)
• относительно одного и того же репо (^/path)
• относительно схемы (//server/path) или
• относительно родительского каталога

Вероятно, вам понадобится 2 или 4 из этого списка. Скорее всего, вам понадобится 4, потому что внешние файлы должны указывать на один и тот же репозиторий.

Короче говоря

Если ваши изображения находятся в папке, такой как trunk/images и у вас есть папка trunk/platforms/windows/images, вы можете либо установить свойство svn:externals на trunk/platforms/windows, чтобы иметь внешний с именем images, указывающий на ../../images (т.е. каталог внешний) или, предположив, что вы хотите использовать другую иерархию или разные имена под trunk/platforms/windows/images, вы можете создать внешние файлы таким образом (images должен существовать подкаталог в WC):

cd trunk/platforms/windows
svn propedit svn:externals images

и добавьте отдельные внешние элементы следующим образом:

../../../images/filename.jpeg other-filename.jpeg

Обратите внимание, что целевые каталоги должны существовать в репозитории и рабочей копии, поэтому для внешнего типа:

../../../images/filename.jpeg foo/other-filename.jpeg

должен существовать подкаталог trunk/platforms/windows/images/foo.

Обновление рабочей копии приведет к тому, что эти внешние элементы будут отображаться в виде файлов версий в рабочей копии. Таким образом, они представляют собой символические ссылки, которые существуют в SVN и проявляются как правильные файлы в рабочей копии, что означает, что все платформы могут обрабатывать их одинаково.