да, это еще один действительный вариант

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

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

Интересно, есть ли что-то подобное, что я могу сделать только с .NET Framework. Я хотел бы знать, когда «все» файлы находятся, а не только один файл в «транзакции». Если ничего не выпекается, возможно, мне следует придумать какое-то ожидание / противодействие, чтобы выполнять свою деятельность только тогда, когда работа «выполнена».

Не уверен, что у меня есть 100% смысл, пожалуйста, кто-нибудь прокомментирует.

Благодарю.

 Tester10111 янв. 2011 г., 22:40
Имеет смысл для меня. Если вы копируете группу файлов в каталог, вы не хотите обрабатывать каждый файл, так как он копируется в каталог. Вы хотите подождать, пока все файлы в группе не будут скопированы, прежде чем предпринимать какие-либо действия.

Ответы на вопрос(3)

Решение Вопроса

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

Если существует много потоков, каждый из которых может записывать набор файлов, то вам нужно как-то связать каждый «конечный» файл с набором файлов, которые он помечает. Одним из способов сделать это было бы включение GUID (или некоторого другого уникального идентификатора) в имена файлов, например,

{ guid1.file1.bin,guid1.file2.bin,guid1.конец }

{ guid2.file1.bin,guid2.file2.bin,guid2.конец }

Другой способ сделать это - заархивировать все файлы из каждого набора в один ZIP-файл, так что вам нужно только следить за отдельными файлами.

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

Если бы я реализовал что-то вроде этого, я бы, вероятно, использовал какое-то имя файла, например~<ANOTHER-UNIQUE-GUID>.tmp мой наблюдатель файловой системы будет наблюдать за одним файлом этого формата, который, в свою очередь, заставляет другого наблюдателя файловой системы ждать файлов, перечисленных внутри. Когда файлы были удалены, временный файл может быть удален.

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

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

 BenAlabaster11 янв. 2011 г., 23:03
@AdamRalph Вы делаете справедливое замечание
 Adam Ralph11 янв. 2011 г., 23:20
да, это еще один действительный вариант
 BenAlabaster11 янв. 2011 г., 23:04
@AdamRalph Или вместо того, чтобы начинать с файла маркера, поместите файлы, которые были завершены вGUID1.end файл. Когда файл .end записан, файлы были успешно скопированы, и вы можете извлечь список файлов из файла .end, не добавляя предварительно каждое имя файла с GUID.
 Adam Ralph11 янв. 2011 г., 22:55
Вы делаете хорошее замечание о возможности множественного написания потоков. Я обновил свой ответ предложением справиться с этим, используя файловое решение end. Ваше предложение определенно сработает, но я бы предпочел не открывать файл маркера и не читать его содержимое. Затем вам придется иметь дело с возможными сбоями на полпути, когда предоставляется неполный набор, и вам, возможно, придется предоставить тайм-аут, чтобы ваш компонент не "ожидал" неполных наборов. С решением 'end' вы не заботитесь о файлах в папке, пока не появится файл 'end'.

ько за изменениями одного файла в каталоге.

Explorer может сделать это, потому что он знает, что вы хотите сделать (скопируйте эти x-файлы здесь).

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

Уловка .end файла, о которой упоминает AdamRalph, является единственной уловкой, которая фактически приближается к тому, что вы хотите сделать.

НТН

Марио

Ваш ответ на вопрос