Если тема еще актуальна, то позвольте, как говорится, сказать:
registration писал(а):
Код:
FOUND-FULLPATH R/W OPEN-FILE-SHARED
GetLastError
32 <> \ 32 -код ошибки ERROR_SHARING_VIOLATION
UNTIL
CLOSE-FILE DROP
Здесь не совсем так. В документации крона вообще ничего не сказано о слове OPEN-FILE-SHARED. Но из приведенного там примера можно сделать вывод, что оно возвращает дескриптор файла (FID), открытого для немонопольного доступа. Там же этот дескрипттор присваивается переменной. А слово CLOSE-FILE используется соответствоенно с этим же дескриптором (или fileID). Т.е. не хватает переменной для дискриптора, открывающего и закрывающего файл. (отсюда, видимо, и проблема стека, т.к. слово возвращает дискриптор)
В кроне так:
Код:
S" test.txt" R/O OPEN-FILE-SHARED THROW list-file ! \ заносим ID файла в переменную, чтобы иметь возможность с ним работать для записи, чтения и пр.
Далее
list-file @ CLOSE-FILE DROP \ закрываем файл по его ID
Вот. Ну и еще несколько замечаний:
Если открывать файл словом OPEN-FILE-SHARED, то каким образом мы увидим, что он занят? Т.е. он может быть занят занят процессом, но не монопольно, т.е. мы не поймем, можно ли его перемещать собственно? Вот если его открыть словом OPEN-FILE (т.е. использовать монопольный доступ), то, отловив ошибку, поймем, что файл уже занят. И, поняв, что он занят, сделаем паузу, проверим еще раз и т.д. пока не освободится.
Ну вот как то так, как я думаю.
Но и это решение выглядит как то костыляво. Вот если через winAPI как-нибудь... Но эта тема для меня темный лес. Однако такая простенькая прога Unlocker показывает все процессы, которые работают с файлом и даже может их легко разблокировать. Не знаю, сделано ли в ней средствами системы или как то другим способом.