-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Corrupt autosave files don't get reset #11375
Comments
@jitseniesen could you take a look at this one :-) ? |
First of all, thank you spyder developers for your work. I understand that the next update will likely solve the reset function, but maybe there is a way to deal with corrupt autosave files in a smoother way (in terms of user interaction), and without resetting other settings. Perhaps popping up a message saying "Opening autosave files caused an error. Do you want to discard the autosave files and try starting Spyder again? These files will be moved to the recycle bin." Maybe sending the files to the recycle bin would be better than deleting them. I am adding more info that might help you understand why the autosave files are being corrupted. Sorry if I am providing too much detail, yet if you need more info please let me know. To begin with, I think that this happened after updating another software: in the first time I updated Firefox from 72.0.2 to 73.0.0, and in the second time, I updated Adobe Reader DC from some recent version to the latest (20.006.20034). I closed Spyder to update adobe (I think I did it for updating Firefox as well, but I might be wrong). This might be a coincidence, though. I closed and opened Spyder on other occasions without a problem, but I cannot say whether I had autosaved files then. I used Spyder for only a few days so far. In both instances, the autosave file is empty (size: 0 kb). Their names are: Further debugging data from the Anaconda Prompt, if it helps:
|
Yes, this is the plan. Until we release a fix, you can delete the What I don't yet understand is how these empty files get created in the first place.
I am not sure I understand you correctly. Do you mean that the creation, access, and modification times of the first file are equal, and that the creation, access, and modification times of the second file are equal, but that the times of the first file are not the same as the times of the second file? |
Regarding the file timestamps, yes, you understood me correctly. The first file was created several hours before I closed the software, after which it did not start (the first startup crash). Likewise, the second file was created several hours beforeI I closed the software, after which the second crash happened (but after the first crash, of course). |
@jitseniesen, why don't we skip those empty pid files until you're able to find a proper solution for this? I mean, this error is pretty serious because it generates a crash at startup. |
I agree. I'm not sure I can do better. |
@jitseniesen just checking if you are going to work on this fix ;-) Cheers! |
I am planning to make at least a start on it on Thursday. |
Thanks a lot! |
Hi, I believe I have found the cause of the corrupt autosave files in my case. I had saved the scripts in a path that contained non-English characters. I get the error both with Arabic and with Hebrew characters separately. When the path does not contain such characters, the autosave folder does contain the temporary file and a pidNNN.txt file with content. Also, when the autosave happens in these situations, I get error messages in the software, as follows. I don't know if this is why @hmaarrfk got corrupt autosave files, too. By the way, the path did not contain spaces.
|
The PR does not address the encoding error in #11375 (comment) so I will open a new issue for this. |
@dn7 That is a good hint for what the underlying issue might is, thanks! However, I don't understand why nobody reported that particular traceback. |
Let me just stress that the |
in my case, I was hacking my kernel, and thingsjust get corrupt, then i have to hard reset my computer, so anything could be the problem. That said, there should have been a guide to get out of that rut. |
@dn7 No, it did not cause me any problems. The two problems need to be solved separately anyway, because the pidNNN.txt files can be corrupted by many different causes (like crashes while they are being written) and we need to handle that gracefully.
@hmaarrfk Agreed, and the next version will take care of that. |
I can't find this directory! where exactly should I look for? |
That's for Linux. On Windows you have to look for |
Thanks all, excited to see this in action! |
I don't know why but it's not there either |
this is the error that it returns `Traceback (most recent call last): ^ |
Using
didn't work
After manually removing
Things started to work again.
Versions
The text was updated successfully, but these errors were encountered: