Опять слэши на конце? Элемента с пустым именем нет в /bd0, но он считается эквивалентным корню в корневых папках дисков типа /bd0/1. Убери слэш, и /bd0 найдётся.
Чтобы проверить возможность чтения папки, нужно прочитать эту папку. Любой способ с разделением проверки и чтения ненадёжен - за время между проверкой и чтением, даже если это два соседних системных вызова, папка может исчезнуть: пользователь вытащил дискету или размонтировал временный диск.
Помогите новичку
-
Сделаем мир лучше!
CleverMouse, спасибо за ответ. Выходит, что лучше слеши в конце совсем не использовать, как ты выше и писала.
Ещё такой вопрос: почему "/cd0/1" содержит "." и ".."? Это не корневая папка?
Как можно проще определить, содержит ли папка "." и ".."? По количеству слешей в пути или по обнулённой дате в атрибутах, или ещё как-нибудь?
Ещё такой вопрос: почему "/cd0/1" содержит "." и ".."? Это не корневая папка?
Как можно проще определить, содержит ли папка "." и ".."? По количеству слешей в пути или по обнулённой дате в атрибутах, или ещё как-нибудь?
Поддерживается ли запись на раздел FAT32, у которого размер кластера 64 кб?
В svn3227 я выделяю несколько файлов и папок и пытаюсь скопировать на такой раздел, после чего на этот раздел невозможно зайти.
На другом разделе размер кластера 32 кб — там всё нормально.
Есть ещё такой раздел: FAT16, размер кластера 64 кб — такая же проблема.
В svn3227 я выделяю несколько файлов и папок и пытаюсь скопировать на такой раздел, после чего на этот раздел невозможно зайти.
На другом разделе размер кластера 32 кб — там всё нормально.
Есть ещё такой раздел: FAT16, размер кластера 64 кб — такая же проблема.
Какая прога выводит справа вверху полупрозрачные сообщения. И как её заставить вывести нужное сообщение?
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Запустить "/sys/@notify" "Какой-то текст"
Из хаоса в космос
Спасибо)
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
В VirtualBox я пытаюсь скопировать на HD файл по частям. При записи возвращается "Device error". И в KFar такая же ошибка. Однако KFM и Eolite файл копируют(или не проверяют ошибку, или игнорируют, или целиком копируют файл, либо ещё как-то). Я увеличил на один байт буфер для копирования в своей программе — удалось скопировать заметно больше, но опять-таки возникла та ошибка. Если же ошибку игнорировать, то файл нормально полностью копируется. Из-за чего может быть такая проблема и как можно её решить?
Попробовал в VirtualBox svn2306. "Device error" не было ни разу, но иногда были вот такие ошибки:
А вот KFar сказал "No memory!", но память-то была:
Копировалась папка, в которой 25 папок и 25 файлов, приблизительно размером 25 Мб.
А на реальной системе в svn3227 тоже были ошибки как в предыдущем сообщении.
А вот KFar сказал "No memory!", но память-то была:
Копировалась папка, в которой 25 папок и 25 файлов, приблизительно размером 25 Мб.
А на реальной системе в svn3227 тоже были ошибки как в предыдущем сообщении.
Опишите кто-нибудь алгоритм удаления папок.
Из хаоса в космос
svn2306 настолько древний, что его нет смысла обсуждать.
Device Error в свежих ядрах - это фейк, реально данные нормально пишутся, я исправила его в r3284.
Device Error в свежих ядрах - это фейк, реально данные нормально пишутся, я исправила его в r3284.
Сделаем мир лучше!
Я примерно так и предполагал, потому чтоDevice Error в свежих ядрах - это фейк
Поэтому для примера привёл svn2306, в котором такого не было.реально данные нормально пишутся
Создаётся дочерний поток.
В нём выделяется память.
И через некоторое время дочерний поток её освобождает.
Но если дочерний поток прибить насильственно, то память уже не освободится.
Как тогда быть? Периодически проверять не прибит ли поток? Или можно как-то проще?
В нём выделяется память.
И через некоторое время дочерний поток её освобождает.
Но если дочерний поток прибить насильственно, то память уже не освободится.
Как тогда быть? Периодически проверять не прибит ли поток? Или можно как-то проще?
Не прибивать дочерний поток. Насильственное прибивание потока - вообще настолько странная операция, что я не могу назвать ни одного случая, когда она действительно нужна. Во всех случаях нужно просить поток умереть самостоятельно, потому что только сам поток знает, когда это будет безопасно.
Сделаем мир лучше!
Логично. Но пользователь может это сделать, например, через panel.Не прибивать дочерний поток.
Если пользователь что-то убивает, это уже личные проблемы пользователя и жаловаться он не может.
Сделаем мир лучше!
Who is online
Users browsing this forum: No registered users and 10 guests