{"action":"created","issue":{"url":"https://api.github.com/repos/PCSX2/pcsx2/issues/838","labels_url":"https://api.github.com/repos/PCSX2/pcsx2/issues/838/labels{/name}","comments_url":"https://api.github.com/repos/PCSX2/pcsx2/issues/838/comments","events_url":"https://api.github.com/repos/PCSX2/pcsx2/issues/838/events","html_url":"https://github.com/PCSX2/pcsx2/issues/838","id":107310048,"number":838,"title":"folderMemoryCard: Should not call 8 times per frame just to increase a flush counter","user":{"login":"avih","id":2164962,"avatar_url":"https://avatars.githubusercontent.com/u/2164962?v=3","gravatar_id":"","url":"https://api.github.com/users/avih","html_url":"https://github.com/avih","followers_url":"https://api.github.com/users/avih/followers","following_url":"https://api.github.com/users/avih/following{/other_user}","gists_url":"https://api.github.com/users/avih/gists{/gist_id}","starred_url":"https://api.github.com/users/avih/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/avih/subscriptions","organizations_url":"https://api.github.com/users/avih/orgs","repos_url":"https://api.github.com/users/avih/repos","events_url":"https://api.github.com/users/avih/events{/privacy}","received_events_url":"https://api.github.com/users/avih/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-09-19T04:47:50Z","updated_at":"2015-09-22T22:09:32Z","closed_at":null,"body":"@AdmiralCurtiss I want to remove this line:\r\nhttps://github.com/PCSX2/pcsx2/blob/f5a38ab/pcsx2/Counters.cpp#L437\r\n\r\nIt calls 8 times per frame into the plugin to increase a flush counter even if no folder memory cards are in use.\r\n\r\nI want to remove this call completely.\r\n\r\nPlease explain to me what are the requirements here and let's find a solution without this call."},"comment":{"url":"https://api.github.com/repos/PCSX2/pcsx2/issues/comments/142436306","html_url":"https://github.com/PCSX2/pcsx2/issues/838#issuecomment-142436306","issue_url":"https://api.github.com/repos/PCSX2/pcsx2/issues/838","id":142436306,"user":{"login":"avih","id":2164962,"avatar_url":"https://avatars.githubusercontent.com/u/2164962?v=3","gravatar_id":"","url":"https://api.github.com/users/avih","html_url":"https://github.com/avih","followers_url":"https://api.github.com/users/avih/followers","following_url":"https://api.github.com/users/avih/following{/other_user}","gists_url":"https://api.github.com/users/avih/gists{/gist_id}","starred_url":"https://api.github.com/users/avih/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/avih/subscriptions","organizations_url":"https://api.github.com/users/avih/orgs","repos_url":"https://api.github.com/users/avih/repos","events_url":"https://api.github.com/users/avih/events{/privacy}","received_events_url":"https://api.github.com/users/avih/received_events","type":"User","site_admin":false},"created_at":"2015-09-22T22:09:32Z","updated_at":"2015-09-22T22:09:32Z","body":"> Consistency is assumed when the card has not been accessed for a certain amount of time\r\n\r\nand\r\n\r\n> I try to make sure writes are done and abort if I can prove they're not, but due to the way PS2 memory cards work you cannot guarantee it\r\n\r\nand\r\n\r\n> The entire point of the emulated-time-since-last-access feature you're trying to remove here is making as sure as we can that we have a valid state\r\n\r\nYou obviously went to great length to reduce the chance of flushing an invalid state, but the fact is you cannot guarantee it, so what happens if this assumption ends up not true? This is a real question which we should be able to answer. E.g. can it end up formatting the host hard drive? would it destroy the folder memory card forever? etc.\r\n\r\nMy main issue with this system is that it's a hack based on guestimation and some arbitrary delay to hopefully end up flushing in a valid state, rather than actually guaranteeing that the sate is valid when flushing, and we don't know what happens when this assumption ends up incorrect.\r\n\r\nThe fact that the implementation details of this delay are not fun is just an unfortunate side effect.\r\n\r\nWhen we're writing to the host filesystem, we need to guarantee correctness first, and if we know we cannot guarantee it, then we must be able to tell what happens when things don't go to plan.\r\n\r\nOnce we know what could go wrong, then we can assess whether or not we can take the risk of flushing an invalid state.\r\n\r\nBut the situation right now is that you tried to explain how terrible would flushing an invalid state be, while also saying you cannot guarantee always flushing a valid state (the effort is good, but it's not guaranteed to work), and you still didn't say what would the side effect of such case be for the user. You basically hope for the best and ignore the case where \"best\" doesn't happen without knowing how it could end up.\r\n\r\nDoes this explain my issue with it?"}}