file.getFreeSpace()

[banach space]

Мне тут подумалось, что раз пока что всё равно 97% времени и мыслей занимает работа, напишу чего-нибудь про неё.
Прекрасная, блин непонятность тут всплыла:
Есть некий код (Java). В нём с периодичностью примерно раз в минуту вызывается некий метод. Метод мониторит расшаренную папку, и если место кончается - шлёт письма админам. В целом, код работает без нареканий. Но в последнее время метод стал примерно раз в сутки засылать ложное сообщение. То есть и место в папке есть и письмо уходит.
В целом выглядит код вот так:

public void toDo() {
    File file = new File(FOLDER_PATH);
    long space = file.getFreeSpace();
    long minDiskSize = settings.getMinDiskSize();
    String absolutePath = file.getAbsolutePath();
    if (space < minDiskSize) {
        log.debug("NOT_OK:\n" +
                "Folder path: [" + absolutePath + "]\n" +
                "Min free space from config: [" + minDiskSize + "]\n" +
                "Free space on server: [" + space + "]");
        //Do some actions
    } else {
        log.debug("OK:\n" +
                "Folder path: [" + absolutePath + "]\n" +
                "Min free space from config: [" + minDiskSize + "]\n" +
                "Free space on server: [" + space + "]");
    }
}

По логам при этом может быть минутой ранее - всё_отлично, вот прям щас - всё_пропало_пишу_письмо, а через минуту уже всё_отлично_живём_дальше.
И ладно бы разница в размере места на харде была маленькая, так тут примерно 300Гб появляются и исчезают.
А до этого пробовала вариацию метода, где и в ифе, и в выводе в лог пользовалась не переменная, а file.getFreeSpace() напрямую. И перед ифом ещё был вывод в лог просто текста. Получалось примерно так: 300 < 10 = true по логам. Т.е. по факту я так понимаю, на момент проверки в ифе было 0, а при выводе в лог уже стало +300Гб, и судя по времени в логах, между ифом и выводом в лог тормозов не было. Т.е. вариант "getFreeSpace долго выполняется и за это время состояние успевает измениться" - тоже не вариант.
Вот. Пока идей чтобы это могло быть нет особо(( Может антивирусы какие или реально внезапно расшаренная папка становится недоступной... Только вот не особо понятно как это всё отлавливать..

@темы: IT

Comments

[Kakou ECTb]

А что в логах? 0?

if (space < minDiskSize && space>0) должно пофиксить

[banach space]

Kakou ECTb, аха, в логах 0. И это фиксит ровно до того волшебного случая, пока внезапно не окажется, что место действительно в 0 ушло. И тогда получится, что как раз-таки самую критичную ситуацию не обработали. Я ещё пробовала проверять file.exists(). Но т.к. получение сведений о месте и существовании папки идет последовательно, а не одновременно, всё равно косяк получается.
Т.е. хочется именно гарантированный способ устранения косяка найти, а не обходные ситуации, типа не отсылать когда 0 или если ноль, то подождать и попробовать ещё раз.

[Kakou ECTb]

banach space, 0 это в байтах? забей весь веник и посмотри сколько останется свободного места, мне кажется, что бару байт то точно должно остаться.

Второй вариант - делать n замеров раз в секунду во время прохода и брать максимальное из них как верный результат.

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

[banach space]

Kakou ECTb, аха, ноль в байтах, забить полностью и проверить уже вчера попробовала - получила результат в 0 байт.
N замеров это как один из вариантов обхода проблемы.
Но мне вот именно что интересно корень всех зол найти. Во-первых заказчик спросит "а что было?" (отвечать-то не мне, а манагеру, но тем не менее, хочется какой-нибудь хороший ответ иметь, а не "сами не в курсе, но вот что-то намутили"), во-вторых недетерминированная проблема может где-нибудь ещё проявиться или через какое-то время тут же с новыми особенностями. И тогда тоже не хорошо получится.

[Kakou ECTb]

banach space, Вот лично мне кажется не стоит просто овчинка-то Потому что мб дело просто тупо в том, что сеть пропадает на доли секунды и привет, чё ты как это фиксать будешь. Емейл админам слать, мол парни - снова сеть на 00:00:01 упала? xD

Если найдёшь причину, отпишись тут, интересно )

[banach space]

Kakou ECTb, в идеале задача либо:
1. Найти и убедиться в том что проблема не на стороне программы. Описать в чём суть проблемы админам заказчика, возможно согласовать с ними использование "хака" и объяснить в чем могут быть последствия (а-ля нет гарантии, что всегда так будет работать), или же вместо этого они починят неисправность со своей стороны. То есть если так происходит из-за микро-обрывов связи - то надо им об этом сообщить, а дальше пусть сами решают чинить они будут или нет.
2. Либо что хуже найти что бага в программе. И либо починить нормально, либо описать почему будет использоваться хак (например починка требует перехода на новую версию чего-нибудь, а заказчик категорически не может).

Если найдёшь причину, отпишись тут, интересно )

Ага, отпишусь)

[Юрий Рэйн]

Меня вот тоже зантриговали).
http://stackoverflow.com/questions/5865735/how-to-get-free-space-of-unc-path-in-java-code
(Если кратко: UNC пути.)
https://bugs.openjdk.java.net/browse/JDK-7036346
http://www.tutorialspoint.com/java/io/file_getfreespace.htm (Тут меня заинтересовало, что проверяют существования файла после того, как узнали размер. Опечатка, или сокральный смысл?)

Дебильное предположение из серии "и такое бывает":
300Гб - это много, но учитывая, что у гипотетического процесса есть, по сути, две минуты (ок-мин-не_ок-мин-ок), если он локален и вызывается, скажем, по крону (раз в сутки, проблема не всегда была), гипотетически, при быстром диске есть шанс создать за это время кэш или своп из темпов и удалить, и если проверка синхронна с операцией удаления, то фокус про 300 < 10 = true при последовательном выполнении инструкций - возможен.

Отсюда вопрос: Ты точно уверена, что у них там не может что-то такое быть недавно настроено?
Контр-аргументы вида "фиг 300Гб так быстро запишутся даже локально", "с чего именно в эту папку", "да что это за процесс такой" и им подобные - понимаю, но просто для исключения заведомо "неожиданно бредовых ситуаций". Сталкивался с подобным.

[banach space]

Юрий Рэйн, аха, про UNC пути читала, но у меня путь к папке указан верно, да и он не меняется в ходе работы. Так что либо работало б либо нет, если б проблема в этом была. Под проблему с большими дисками тоже не подпадает - там всего пол терабайта места. Про то когда проверяют - по-моему просто by design. Там внизу немного тестов, судя по которым как ни проверяй, всё равно на глюк можно нарваться.

void-dragon, я не уверена, но они говорили, что ничего не меняли) Т.е. да, такое тоже возможно, то что ты выше описал. Но диск этот (папка) теоретически отдан на работу импорта\экспорта, где файлы порциями приходят, обрабатываются, потом удаляются разными компонентами софта (по части из него я знаю только что он есть и с файлами взаимодействует).

void-dragon, Юрий Рэйн, Kakou ECTb, Я вот тут пока что корень проблемы не нашла, но прихожу к выводу, что мне не нравится реализация метода freeSpace =)
Написала тут небольшой тест, который имитирует рандомное подключение и отключение папки:
1. Первая программка монотонно создаёт и удаляет одну и ту же папку:

    public void create(boolean isCreate) {
        try {
            File file = new File(fpath);
            if (isCreate) {
                if (!file.exists()) {
                    file.mkdir();
                }
            }else{
                file.delete();
            }
        }catch (Exception e){
            e.printStackTrace();
        }
    }

2. Вторая постоянно, но с рандомным слипом, мониторит ту же папку и пишет логи:

    public void monitorFolder() {
        File file = new File(fpath);
        while (true) {
            try {
                Integer randDelay = ThreadLocalRandom.current().nextInt(0, 1000 + 1);
                Thread.sleep(randDelay);
                long diSpace = file.getFreeSpace();
                boolean isExists = file.exists();
                System.out.println("freeSpace = [" + diSpace + "], isExists = [" + isExists + "]");
            } catch (InterruptedException ex) {
                Thread.currentThread().interrupt();
            }
        }
    }

В логах видим в итоге все 4 возможных состояния
freeSpace = {0}, isExists = {false}
freeSpace = {0}, isExists = {true}
freeSpace = {0}, isExists = {true}
freeSpace = {991182094336}, isExists = {false}
freeSpace = {0}, isExists = {false}
freeSpace = {0}, isExists = {false}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {0}, isExists = {false}
freeSpace = {991182094336}, isExists = {false}
freeSpace = {991182094336}, isExists = {false}
freeSpace = {0}, isExists = {false}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {false}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {0}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {0}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {0}, isExists = {false}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {991182094336}, isExists = {true}
freeSpace = {0}, isExists = {false}


Вот такая вот фигня, в итоге вот эти 2 состояния шизокрылые:
freeSpace = {0}, isExists = {true}
freeSpace = {991182094336}, isExists = {false}

А в JDK 7 уже есть нормальное решение проблемы: тык. При таком же постоянном удалении\создании папки и рандомных проверках, если папки нет, вылетает

exception

java.nio.file.AccessDeniedException: D:\TestDir
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsLinkSupport.getFinalPath(WindowsLinkSupport.java:107)
at sun.nio.fs.WindowsFileStore.create(WindowsFileStore.java:83)
at sun.nio.fs.WindowsFileSystemProvider.getFileStore(WindowsFileSystemProvider.java:482)
at java.nio.file.Files.getFileStore(Files.java:1461)
at Mail.getPathFilesystem(Mail.java:64)
at Mail.monitorFolder(Mail.java:27)
at Main.main(Main.java:7)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134). Что как-то однозначнее.

Не знаю как в Java-е, а в пыхе, в доках, прямо сказано, что состояния методов типа file_exists() кэшируются:
"Замечание: Результаты этой функции кэшируются. Более подробную информацию смотрите в разделе clearstatcache()."
Отсюда: http://php.net/manual/ru/function.file-exists.php
Соответственно, считать результат проверки этим методом в php "надежным" - нельзя.

Если в джаве похожий механизм, это бы объяснило "шизокрылые состояния".
Соответственно, "велосипеды" - наше все

[Юрий Рэйн]

http://www.coderanch.com/t/277917/java-io/java/File-exists-returns-true А ведь кэширует!
Тогда получаются варианты:
1) использовать isFile()
2) добавлять Sleep
3) Пытаться открывать файл на чтение.