Moneyguru

Sugonyako
Дело не в программе.
Я не имел ввиду только саму программу Moneyguru - здесь участвует несколько программ.
Кроме того, вроде бы в подобного рода прогах можно выбрать и другой формат, имхо, xml не совсем удобный формат ... если возможно, попробуй сменить формат, хотя бы просто для проверки. Если ничего не изменится, смотри настройки.
А вообще, по хорошему, нужно узнать кто в этом замешен и др., а для этого осваивай методы отладки и добычи информации. Ну нет смысла гадать ...
Ошибки не исчезают с опытом - они просто умнеют
да вообще программа глючная что капец, то пишет то не пишет то не все отображает, в общем стало понятно что сам автор на нее забил https://github.com/hsoft/moneyguru#unmaintained

moneyguru --debug
судя по дебагу с системным временем все нормально, и сами данные с датой сохраняется в xml тоже нормально, но вот когда идет считывание даты из xml то все даты в полях формы уменьшаются и соответственно при следующем сохранении даты уже искажены. То есть похоже это трабла самой программы, возможно после обновления одного из внешних компонентов из которых состоит программа их поведение изменилось но вот соответствующе адаптировать код программы уже некому.
Всех благодарю. Решил поставить Gnucash. Она "тяжелая" но надежная.
red
сами данные с датой сохраняется в xml тоже нормально, но вот когда идет считывание даты из xml то все даты в полях формы уменьшаются и соответственно при следующем сохранении даты уже искажены. То есть похоже это трабла самой программы
Стало интересно, похолодало, делать нечего .. и решил посмотреть ... установил, создал для проверки файл xml ~/ttt.moneyguru, поэкспериментировал - действительно даты уменьшаются, потрейсил
Вывод трассировки:
При открытии проги - открывается и читается созданный файл xml ttt.moneyguru, дата правильная (2019-09-16), объем тоже (485 байт)
28768 openat(AT_FDCWD, "/home/vasek/TTT/TEMP/1/ttt.moneyguru", O_RDONLY|O_CLOEXEC) = 12
28768 read(12, "<?xml version=\"1.0\" … <transaction date=\"2019-09-16\" ...) = 485
…..
PS - правда замечен один нюанс - файл (дескриптор) после открытия и чтения не закрывается, висит некоторое время открытым (причин может быть несколько, разбираться не стал) - 28768 close(12 <unfinished …>
…….
А вот дальше непонятна мысль программиста - использование системного вызова writev (работает также как и write, но записывает несколько буферов) … но почему дважды и почти похожие … и почему 72 байта, не понял - допустим так нужно
28768 writev(3, [{iov_base="\22\0\22\0\6\0 \1\204\1\0\0o\1\0\0\10\0\0\0000\0\0\0moneyGuru (/home/vasek/TTT/TEMP/1/ttt.moneyguru)", iov_len=72}], 1) = 72
28768 writev(3, [{iov_base="\22\0\22\0\6\0 \1'\0\0\0\37\0\0\0\10ptr0\0\0\0moneyGuru (/home/vasek/TTT/TEMP/1/ttt.moneyguru)", iov_len=72}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 72
Но вот дальше снова открывается наш файл и в него уже пишется дата на 1 день меньше
28768 openat(AT_FDCWD, "/home/vasek/TTT/TEMP/1/ttt.moneyguru", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 12
28768 write(12, "<?xml version=\"1.0\" … <transaction date=\"2019-09-15\" ...) = 485
И такое подозрение, что эта дата изменилась в буфере (при вызове writev) … но могу и ошибаться - глубоко копать не стал.
PS - и довольно часто вызывается
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1535, ...}) = 0
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.