У меня есть два процесса: один для последовательного создания набора файлов, а другой - для чтения один за другим в том же порядке.
Первый процесс - это последовательное создание файлов и переход в другой каталог, как показано ниже.
file = File.open(file_path, "a:UTF-8")
file.write "Write something.."
file.write "Write something.."
file.write "Write something.."
file.close
FileUtils.mv(file_path, new_dir) #move the file to another directory
Второй процесс должен читать файлы в том же порядке, в котором они создаются. Итак, я сортирую файлы по mtime, читаю, а затем удаляю файл.
files = Dir.glob(new_dir + "*").sort_by{ |f| File.mtime(f) }
if !files.empty?
files.each do |file|
# reads the file delete it
end
end
Это работает в большинстве случаев, но, как ни странно, иногда созданный позже файл улавливается читателем, нарушая последовательность.
Одна вещь, которую я заметил, является общей для этого сценария: n-й файл намного больше, чем n + 1-й файл. Но это не должно быть проблемой, поскольку я создаю файлы последовательно и сортирую с помощью mtime.
Мне трудно найти здесь основную причину. Это из-за того, как ввод-вывод обрабатывает файлы подчеркивания? Может из-за того, что File.mtime не учитывает миллисекунды? Но я добавил 1 секунду сна между каждым созданием файла, это уменьшило количество вхождений, но это все равно происходит.
Мне довольно сложно диагностировать проблему, учитывая, что вы не предоставили общий доступ к коду, который создает файлы, или к коду, который читает файлы, и при этом вы не добавляли какие-либо отладочные данные во время выполнения процесса. Итак, вот первое, что я бы сделал, чтобы начать диагностировать это, на вашем месте: давайте выясним, на какой стороне есть ошибка - действительно ли файлы читаются не в порядке mtime, или они написано не в порядке mtime? Затем давайте увеличим масштаб кода, ответственного за создание такого поведения. Если вы его нашли, укажите в вопросе код виновности.
Как предложил @mudasobwa, может помочь добавить номер к имени файла - чтобы вы знали, в каком порядке mtime файлы предполагаемый должны быть записаны / прочитаны. Это должно прояснить, действительно ли mtime записываются не синхронно или просто читаются в неправильном порядке.
@TomLord mudasobwa предложил вообще избавиться от сортировки по mtime и использовать для сортировки вручную сгенерированное число.
Я добавил к вопросу код читателя. Я добавил метку времени к имени файла, и на основе журнала отладки читатель выбрал не тот файл. Файл, который он читает первым, имел более высокую отметку времени в имени файла.
@mudasobwa Я знаю, но я опирался на эту идею, чтобы помочь отладить текущий дизайн, а не просто отказаться от него (возможно, нежелательно менять имена файлов?)
@Yasitha Я до сих пор не знаю, что делать с вашим кодом ... Вы хотите сказать, что Dir.glob(new_dir + "*").sort_by{ |f| File.mtime(f) } упорядочивает файлы нет по их mtime ?! Или, может быть, mtimeизменения после этой первоначальной выборки данных? У меня по-прежнему нет информации о журналах, чтобы продолжить, или каким-либо способом воспроизвести проблему.
Сделайте .sort_by{ |f| File.mtime(f) } → .sort_by{ |f| File.mtime(f).tap { |mt| puts [f, mt].inspect } }, чтобы диагностировать mtimes.
Рассмотрите возможность использования блочной структуры типа Ruby File.open(...) do |f| ... end для обработки файловых операций. Это имеет то преимущество, что автоматически закрывает файл в конце блока, чтобы вы не могли случайно его забыть.

В чем была бы проблема, чтобы добавить увеличивающийся счетчик в качестве суффикса к именам файлов и читать их в естественном порядке?