Colon (:) появляется как косая черта (/) при создании имени файла

Я использую дату и время для маркировки нового файла, который я создаю, но когда я просматриваю файл, двоеточие - это косая черта. Я развиваюсь на Mac, используя 10.7 +

Вот код, который я использую:

 File.open("#{time.hour} : 00, #{time.month}-#{time.day}-#{time.year}", "a") do |mFile|
        mFile.syswrite("#{pKey} - #{tKey}: \n") 
        mFile.syswrite("Items closed: #{itemsClosed} | Total items: #{totalItems} | Percent closed: % #{pClosed} \n") 
        mFile.syswrite("\n")
        mFile.close
     end

Вот результат (если время составляет 1 час):

13 / 00, 11-8-2012

Почему это происходит и как я могу это исправить? Я хочу, чтобы результат был:

13:00, 11-8-2012

Ответ 1

Когда-то, перед Mac OS X, : был разделителем каталогов вместо /. Очевидно, OS X 10.7 все еще пытается исправить такие программы. Я не знаю, как вы можете это исправить, если вам действительно нужен :. Я бы опустил это: -).

EDIT: после немного большего поиска этот документ USENIX описывает, что происходит. Правило, которое они используют, очевидно, таково:

Еще одна очевидная проблема - разные разделители путей между HFS + (двоеточие, ':') и UFS (слэш, '/'). Это также означает, что имена файлов HFS + могут содержать символ косой черты, а не двоеточие, а для имен файлов UFS - обратное. Это было легко решить, хотя это включает в себя преобразование строк взад и вперед. Реализация HFS + в ядре VFS слой преобразует двоеточие в косую черту и наоборот при чтении и записи на диск формат. Таким образом, на диске разделитель представляет собой двоеточие, но на уровне VFS (и, следовательно, что-либо над ним и ядром, например, libc) это косая черта. Однако традиционная Mac OS инструментальные средства ожидают двоеточия, поэтому над уровнем BSD основной инструментарий Carbon делает еще один перевод. В результате приложения Carbon видят двоеточия, и все остальные видят косая черта. Это может создать видимую пользователем шизофрению в редких случаях имен файлов содержащие символы двоеточия, которые отображаются в приложениях Carbon в виде косой черты, но для BSD-программ и Cocoa приложений как двоеточие.

Ответ 2

В то время как OS X "является операционной системой unix, она также получает совсем немного своего кода, API, стандартов и т.д. из Mac OS 9. В unix пути к файлам имеют" / ", разделяющие элементы, а": "- разрешено в именах отдельных файлов и каталогов. В Mac OS 9 это было наоборот: пути к файлам имели": "между элементами, а" /" - в отдельных именах файлов. Когда Apple разработала OS X, они оказались вынуждены поддерживать некоторые API-интерфейсы, которые использовали пути к файлам в стиле unix, и некоторые API-интерфейсы, которые использовали пути в стиле 9-го уровня, и им приходилось работать с одной и той же файловой системой.

То, что они сделали, это обмен запятыми разделителями и допустимыми символами в зависимости от контекста. Если вы пишете (/run) программу, которая использует unix API для доступа к файловой системе, вы увидите файлы с двоеточиями в своих именах и косые черты, разделяющие элементы пути. Если вы пишете (/run) программу, использующую старые API OS 9 (или их производные), вы увидите файлы со слэшами в своих именах и двоеточиями, разделяющими элементы пути. См. Яблочный разработчик Q & A # 1392 и заметки по указанию путей в AppleScript для более подробного обсуждения.

(Существуют и другие отличия. Путь unix является абсолютным, если он начинается с разделителя ( "/" ), а абсолютные пути начинаются в верхней части корневого тома. Путь OS 9 является абсолютным, если он начинать с разделителя, а абсолютные пути OS 9 начинаются с имени тома. Таким образом, путь unix "/tmp/foo: bar" эквивалентен пути OS 9 "Macintosh HD: tmp: foo/bar".)

Итак, какой символ действительно находится в имени файла, косой чертой или двоеточием? Ну, имя файла довольно абстрактное, но если вы спрашиваете о байтах, которые на самом деле хранятся на диске... если он на томе HFS + (aka Mac OS Extended), он хранится в файловой системе, которая был разработан для работы с API-интерфейсом OS 9 (хорошо, технически Mac OS 8.1), поэтому он позволяет слэш, но запрещает двоеточия, поэтому на томе HFS + файл "действительно" имеет косую черту в имени. OTOH, если вы храните файл на томе unixish, он будет сохранен с использованием соглашения unix, а "действительно" имеет двоеточие в имени. Но разница не имеет значения, если вы не читаете необработанные байты с диска или не записываете драйвер файловой системы...

Наконец, почему Finder отображает противоречивый символ имени файла как косой черты, а не двоеточие? Я почти уверен, что это в основном инерция. Finder даже не полностью согласен с этим, так как если вы используете опцию Go To Folder (Command-Shift-G) и набираете "/Users/Shared", она рассматривает это как путь unix. Если вы наберете "Macintosh HD: пользователи: общий", он не знает, о чем вы говорите. Кроме того, если вы запустите touch /tmp/foo:bar, попробуйте перейти к нему в папку "Перейти к папке":

Работает "/tmp/foo: bar".
Ввод "/tmp/fo", а затем нажатие вкладки автоматически запустит ее в "/tmp/foo/bar/", которая работает.
Ввод "/tmp/foo/bar/" завершается с ошибкой, даже если он точно совпадает с автозаполнением.
Ввод "/tmp/foo", а затем нажимаем вкладки "автозаполнения" на "/tmp/foo/", которые не могут быть автозаполнены и не работают вообще.

Обновление: как указал Конрад Рудольф, поведение Go To Folder изменилось с El Capitan, и я больше не могу использовать его для доступа к папкам, содержащим противоречивый характер.

Ответ 3

Чтобы избежать как можно большего числа проблем при работе с File именами, путями и различными операционными системами, вы действительно должны воспользоваться преимуществами встроенные File методы, такие как join, dirname, basename, extname и split. Они стараются избегать системных зависимостей и пытаются дать вам программный способ генерации допустимых имен файлов в кросс-платформе.

Эта проблема была намного хуже, когда Apple использовала старую операционную систему Macintosh. Переход на Mac OS помог, потому что они потеряли использование : в качестве разделителя, однако те люди, которые вручную создавали имена файлов, обнаружили нарушение кода, потому что генерировали неправильные разделители, тогда как использование библиотек справлялось с проблемой.

Поскольку эта конкретная проблема не является ошибкой и не является элементом управления Ruby, но Apple, я бы сказал, что это не проблема Ruby, это проблема визуализации, и если вы хотите, чтобы имя файла напоминало то, что Finder соответственно отображает код.