Sigil "not responding - must close" repeatedly

[Trane]

Originally Posted by DiapDealer

I'd try putting it back to the default "/Users/<username>/AppData/Local/Temp" to see if it makes a difference. Wiping the Sigil.ini would reset the Temp driectory.

Indeed it did.

Sigil always cleans up after itself (except after a crash), so space shouldn't be an issue at all. I don't really recommend altering the Temp folder setting unless the default proves to be problematic (as mentioned in the Mac scenario above).

Reverting to the default will at least eliminate that as a potential problem.

Agreed and good to know.

[Trane]

Originally Posted by BetterRed

In contrast to you - My desktop has 7 folder shortcuts, language bar, and the recycle bin - but my tray has 26 icons

BR

I have W7 config'd to use the old quick launch toolbar and have 20 icons on that. The desktop icons are mostly shortcuts to folders I frequently use. It's funny how people organize their computers. Psychologists could probably tell a lot about someone just by looking at how their computer is configured!

[Trane]

Originally Posted by DiapDealer

Yes. That would be consistent with Book View behavior. I try to edit as little as possible (meaning never) in Book View.

The thing is, I place a picture (in Code View) then I have to make sure it all looks okay, and invariably I see something I could polish up a bit, so I just do it in BookView quickly b/c that's where it's easiest to see how it's looking and flowing.

IOW, I hear you, but I will not stop polishing in Book View. It's much faster and more efficient, for me, using that mode, than having to look past all the code. It's also much easier on my eyes. Today I worked 10hrs on it, minus the time spent here. I can't look at that font/code for 10 hours, it's too much eye strain. I would rather use CTL S constantly even if it means Sigil crashes regularly. But I hope that won't be the case.

I am hoping generating a new .ini -- which also put the temp directory in the native spot -- will do the trick.

EDIT: But that IS why I go into Code View to place an image and write the code around it (img class, figure caption, etc.) That's my compromise.

[Trane]

I was going to start a new thread but this might be related. Just sat down to work, Sigil was working fine last night after creating the new .ini, though didn't use it too long. Now this morning, went to start Sigil and got a popup error saying Sigil must close, but it was an internal Sigil dialog box (not the Windows dialog) and Sigil never actually opened... the popup came up a split second after clicking the shortcut icon to start the program:

Error info: /OEBPS/content.opf: The system cannot find the path specified.
Sigil version: 0.9.7
Runtime Qt: 5.6.1
Compiled Qt: 5.6.1
Platform: Windows SysInfo ID 144

(I don't leave my computer on overnight, so it had a clean reboot this morning.)

Entered OEBPS in Search programs and files and nope, the directory could not be found. I can reinstall Sigil of course, but thought I should mention this in case it might have something to do with the previous crash issue.

[DiapDealer]

Originally Posted by Trane

Entered OEBPS in Search programs and files and nope, the directory could not be found.

There'd be no reason to find that path. It only exists in the epub or in Sigil's scratch directory when Sigil is open.

There is definitely something weird going on. It's like Sigil can't create the default empty epub when launching. Which traditionally suggests permission issues with regard to the scratch area Sigil wants to use.

When deleting/replacing Sigil's ini file, always make sure Sigil isn't running when doing it.

[KevinH]

That strange path seems to indicate that something is either preventing Sigil from writing to is scratch/temp space or that somehow TEMP on your windows box has issues? This is so contrary to any behaviour I have seen on Sigil that I find things are really strange.

Something (antivirus?) seem to be preventing Sigil from making and using the temp files its needs even on a fresh start-up. On boot Sigil will create an empty epub but that "/OEBPS/..." seems to be indicating an incomplete path of some sort where the drive and path to the Temp folder has somehow been set to a null string instead of a real path to a proper Temp area.

DiapDealer, do you think it would help if we start fresh, but set Sigil's TEMP on windows to some local folder she definitely has full write/read access to somewhere in her home directory just to rule out permissions issues?

KevinH

[Trane]

OK well I am to blame for this, I think.

@ DDealer - yes. Always with Sigil not running. But last night after I renamed the old .ini and then restarted Sigil, we were also talking about how it would default to putting the Temp folder in the native place, as I had it set to use my J drive.

So you mentioned where the default Temp is usually located and I navigated there (with Sigil closed) and saw indeed (User/%/AppData/Local/sigil-book/sigil/) and so assumed it was no longer using the J:\Sigil Temp folder. So I went to J:/Sigil Temp and saw 200MB of Sigil Folders that were left from when the program would crash. (I remember Dealer saying it cleans up after itself except if it crashes.) So I deleted the entire directory with all subfolders, b/c I didn't think it was using it anymore.

Now I can't remember if I opened Sigil after I did that (last night) again, but may not have. So maybe my deleting the J temp folder caused this.

And to KevinH - no AV running. (Use Sandboxie.) And no permissions problems. I'm sure it's that I deleted the J Temp folder and Sigil was still using it b/c I had not gone into preferences and removed that optional setting. (I was under the impression that renaming the old .ini and allowing Sigil to replace it would reset the location of the temp to default.)

Anyway.... am going to just reinstall... unless there is something else one of you wants me to do... will wait a short bit for replies.

[KevinH]

Here is some interesting reading ... it seems Adobe Acrobat under specific conditions is changing the permissions on some Windows users temp folders ...

Just in case this is the issue:

http://www.tomshardware.com/forum/33...mission-itself

[Trane]

An afterthought.... doubt this could be the cause but a couple weeks ago or so when this all came up, I thought maybe Sigil was crashing due to lack of available memory. I only have 4GB RAM and there was about 4GB more in virtual memory. I know Sigil is light on resources but I also had Adobe open much of the time and when Sigil would crash it would seem to consume all CPU resources (which I know isn't memory) but the available memory was also on the low side (looking at Task Manager) at something like 715MB. So I up'd the virtual memory from 4GB to about 6GB.

I assume Windows would not use sectors currently occupied by data even if they were just temp folders... like the native Sigil temp folder... which I am realizing now was probably created when I first installed Sigil, before I changed the setting to use the J directory, which I did soon after installing it, but not immediately. (And I have been using Sigil for maybe 7 months now.) IOW, that native temp folder I found last night after I changed the .ini was probably created back when I installed Sigil, not last night.

HA. I just looked at the creation date and it was Feb 2014... I forgot I installed Sigil a few years back but didn't start using it until several months ago.

[Trane]

Originally Posted by KevinH

Here is some interesting reading ... it seems Adobe Acrobat under specific conditions is changing the permissions on some Windows users temp folders ...

Just in case this is the issue:

http://www.tomshardware.com/forum/33...mission-itself

Interesting... but I just checked my temp Sigil folder and the permissions are System, [my username], and Admin... and I have full permissions (as I do everywhere).

Also, I have Adobe set to use a Temp folder in J... where I have all my programs set to use their temp folders... That's my scratch drive. There is nothing on it but Temp folders [for the programs that require those].

[KevinH]

BTW, Sandboxie has numerous issues with Temp file creation (even in the user's own area) up to and including current releases. A google search on Sandboxie and temp folder permissions also leads to some interesting reading. I am not sure how Sandboxie prevents access to user temp folders or even why.

[Trane]

Originally Posted by KevinH

BTW, Sandboxie has numerous issues with Temp file creation (even in the user's own area) up to and including current releases. A google search on Sandboxie and temp folder permissions also leads to some interesting reading. I am not sure how Sandboxie prevents access to user temp folders or even why.

Been using SBIE for about 3 years with no issues. Only sandbox the browser. I really can't see that being the issue. (But SBIE's temp directory IS on C... that's the one program I run in its default configuration b/c it will run more efficient on C.)

FWIW though, the SBIE temp folder (or sandbox) is in the root.

[KevinH]

Please double check that just opening Acrobat has no impact on your permissions in your user temp area (not just the temp area used by acrobat) and the permsioons of Sigil own temp folder and its contents.

Please do the same for Sandboxie.

When the next error happens, please check permissions on the temp area and Sigil's specific temp folder and all its contents to rule out permissions completely, as some poorly written apps seem to force inhertance of permissions on subdirectories of the main temp directory.

[Trane]

Originally Posted by KevinH

Please double check that just opening Acrobat has no impact on your permissions in your user temp area (not just the temp area used by acrobat) and the permsioons of Sigil own temp folder and its contents.

Please do the same for Sandboxie.

When the next error happens, please check permissions on the temp area and Sigil's specific temp folder and all its contents to rule out permissions completely, as some poorly written apps seem to force inhertance of permissions on subdirectories of the main temp directory.

OK, well I just opened Adobe (it's Photoshop CS6 I am using) and SBIE is running for the browser, and the permissions for the Sigil temp file are unchanged. I tried starting Sigil and got the standard Windows dialog, that the program needs to be closed. The first time I tried to start Sigil this morning I got the Sigil error, which I posted earlier. But with all subsequent tries it's been the standard Windows dialog box saying the program needs to be closed. (To be clear, the GUI never appears. So to the user it doesn't appear the program ever opens, but obviously processes are opened... generating the "close program" error.)

[DiapDealer]

It's entirely possible that there's no real problem right now. I can easily see Sigil freaking out if the folder specified as the Temp directory (in preferences/ini) no longer existed when Sigil is opening.

I still don't know that I'd completely reinstall yet. Make sure the Temp folder Sigil is looking for exists, and then after Sigil launches, use the "Auto" button to set the Temp folder back to Qt/Sigil's default. Then restart Sigil.

Reinstall if you like (though your preferences/plugins will persist if you don't delete Sigil's AppData/Local/sigil-ebook folder). It could be easier.