Странный случай: текстовый файл, который существует и не существует. t exist
rsync --ignore-existing --recursive /source_dir /destination_dir
это то, что вы имеете в виду?
В одном каталоге не может быть двух файлов с одинаковыми именами. Имена файлов по определению являются уникальными ключами.
То, что у вас есть, почти наверняка особенный персонаж. Я знаю, что вы их проверяли, но как именно? Можно сказать что-то вроде ls * gff | hexdump -C , чтобы найти специальные символы. Любой байт с установленным старшим битом (то есть шестнадцатеричные значения между 80 и FF ) будет свидетельством того, что что-то пошло не так. Все, что ниже 20 (десятичное 32), также является специальным символом. Еще один намек - наличие точек . справа, текстовый столбец hexdump -C .
Существует множество символов, которые выглядят как символы US ASCII в UTF-8. Даже в US ASCII 1 и l часто могут выглядеть одинаково. Затем у вас есть C из кириллицы (U + 0421), греческая полулунная сигма (U + 03F9, также в точности как C), кириллица / греческий нижний регистр «o» и т. Д. И это только видимые. Там может быть довольно много невидимых символов Unicode.
Пояснение: почему высокий бит означает, что что-то пошло не так? Имя файла «Clon1918K_PCC1.gff» выглядит как 100% 7-битный американский код ASCII. Если ввести его через hexdump -C , получится следующее:
00000000 43 6c 6f 6e 31 39 31 38 4b 5f 50 43 43 31 2e 67 |Clon1918K_PCC1.g|
00000010 66 66 |ff|
Все эти байтовые значения ниже 0x80 (8-й бит очищен), потому что все они являются 7-битными кодовыми точками US ASCII. Кодовые точки Unicode от U + 0000 до U + 007F представляют собой традиционные 7-битные символы ASCII США.Кодовые точки U + 0080 и выше представляют другие символы и закодированы как от двух до шести байтов в UTF-8 (в Linux попробуйте man utf8 для получения подробной информации о том, как это делается). По определению, UTF-8 кодирует кодовые точки US-ASCII как сами себя (т.е. шестнадцатеричный символ ASCII 41 , Unicode U + 0041, кодируется как один байт 41 ). Кодовые точки ≥ 128 кодируются как от двух до шести байтов, каждый из которых имеет восьмой бит . Наличие символа, отличного от ASCII, может быть легко обнаружено этим без необходимости декодировать поток . Например, скажем, я заменяю третий символ в имени файла, 'o' (ASCII 6f , U + 006F), символом Unicode 'U + 03FB GREEK SMALL LETTER OMICRON', который выглядит следующим образом: 'ο '. hexdump -C затем производит следующее:
00000000 43 6c ce bf 6e 31 39 31 38 4b 5f 50 43 43 31 2e |Cl..n1918K_PCC1.|
00000010 67 66 66 |gff|
Третий символ теперь закодирован как последовательность UTF-8 ce bf , каждый байт которой имеет свой 8-й бит. И в данном случае это ваш признак неприятностей. Также обратите внимание, как hexdump , который декодирует только 7-битный ASCII, не может декодировать единственный символ UTF-8 и вместо этого показывает два непечатаемых символа ( .. ).
попробуйте переименовать файл с помощью nautilus, но введите желаемое имя (не копируйте вставку). Это обязательно должно удалить любые специальные символы. Это может быть даже пробел после / перед именем файла, невидимый для вас, но видимый для ОС и программ. Я обычно использую mc, чтобы справиться с очень странными именами файлов.
Задумывались ли вы о наличии руткита? Когда-то у меня был доступ к машине Solaris, на которой был установлен руткит. Файлы с именем '* 01' не отображались с помощью ls * 01 или ls -altr , но отображались с echo * 01 . При установке руткита были изменены ls (и ряд других исполняемых файлов), поэтому некоторые файлы и процессы не появлялись при обычных обстоятельствах. Ваше описание очень похоже на руткит, с которым я столкнулся.
В linux невозможно иметь два файла с одинаковым именем в одном каталоге.
Попробуйте открыть vim родительский каталог, затем перейдите к файлу "stranger" и посмотрите, сможете ли вы получить к нему доступ
Один тире для одного ( или нескольких ) сокращенных аргументов:
команда -abcДвойное значение для одиночных, не сокращенных аргументов:
команда --alice --barry --catherine
Важно отметить, что это только конвенция. Любая команда может принимать любые аргументы в любом стиле (при условии, что они удалены из оболочки), независимо от тире. Если бы наш пример команды был запрограммирован, чтобы принять их, следующие могли бы быть действительными синонимами вышеприведенных примеров:
command abc
command alice barry catherine
Это, вероятно, ужасные примеры, но я пытаюсь понять, что это соглашение о способе обработки аргументов как непозиционных аргументов. Некоторые не хотят этого. Некоторые вещи просто используют одинарные тире. Некоторые вещи используют символы, отличные от тире (я видел перекрестно скомпилированные приложения Windows, все еще использующие /)... Это действительно не имеет большого значения.
Ошибки указывают на аппаратную проблему с диском, но только в секторах, содержащих данные.
Причина того, что в Windows вы не видите этих ошибок (до сих пор), вероятно, вызвана различиями в программном обеспечении просмотра файлов: большинство браузеров файлов Linux читают больше информации о файлах, из файла при открытии папки, чем это делает проводник Windows. Это делается, чтобы сделать предварительный просмотр, и иметь метаданные для файлов доступны. Вероятно, Windows получает это только при явном запросе.
Можно попробовать скопировать все файлы из Windows на отдельный диск. Если это работает, запустите какой-нибудь тщательный дисковый анализатор на исходном диске, прежде чем продолжать использовать его (после создания полной резервной копии).
-121--244913-Попробуйте использовать
find. -iname Clon1918K_PCC1.gff
this файл может находиться в любом подкаталоге, а не в текущем каталоге.
Вероятно, что в имени файла есть «странный» символ: возможно, пробел, или управляющий символ, или не-ASCII-символ, который выглядит как ASCII-символ. Поскольку файл соответствует * .gff , любой специальный символ будет перед . .
Запустите LC_ALL = C ls -l --quoting-style = c * .gff , чтобы увидеть однозначное представление имени файла.
Запустите mv -i * .gff Clon1918K_PCC1.gff , чтобы переименовать файл в известное имя.
На случай, если кто-то наткнется на это и прочитает другие ответы... Вы могли бы прыгать через множество обручей или играть с подстановочными знаками, как говорится в некоторых ответах, или просто использоватьls -b-Я помню это как "двоичный".
Завершение табуляции в оболочке должно автоматически заключать символ в кавычки, но вы можете либо использовать что-то, что не является оболочкой (, например Nautilus ), либо использовать стиль оболочки -escape-кавычек с lsдля создания удобная строка перед -в кавычках для других команд. Я использовал этот странный пример файла в другом более длинном ответе в другом месте, но он также актуален и здесь:
sauer@lightning:/tmp/test> ls
a??file
sauer@lightning:/tmp/test> ls --quoting-style=shell-escape
'a'$'\t\033''file'
sauer@lightning:/tmp/test> mv -v 'a'$'\t\033''file' regular_filename
renamed 'a'$'\t\033''file' -> 'regular_filename'