Empty config.xml (in low space conditions?)

[Keisial]

Yesterday, my scripts worked flawlessly (or at least some subset).

Today, I notice they are not running. Looking at "User scripts" tab, it shows that I have 0 scripts.

gm_scripts/config.xml is empty, too.

The scripts are thanksfully still there.

I would have expected that moving config.xml out of the way would regenerate it, but it creates another empty config.xml.
I briefly had a full partition, so greasemokey probably tried to store the file, and it probably truncated it, and was then unable to recreate it.
Mind you, this is just guessing. I didn't change any script, so there was no reason for greasemonkey to modify the file. And when changing it, it should be done in a way that doesn't leave empty files behind.

Now I need to figure out a way to script their readdition...

[arantius]

I'd be very inclined to WONTFIX the extreme edge case of an absolutely full disk.

I would have expected that moving config.xml out of the way would regenerate it,

This is most definitely not true. This file is the primary/only source of some information, it cannot be recreated when missing.

I didn't change any script, so there was no reason for greasemonkey to modify the file

A rather wide variety of conditions will trigger saving this file; as mentioned it stores a lot of things like enabled/disabled status of each script.

[Keisial]

I'd be very inclined to WONTFIX the extreme edge case of an absolutely full disk.

Sure it's not common, and not too easy to test, but disks do get full, and disk quotas get reached.

Would you feel happy if when the disk gets full your text processor truncated your documents just because you opened them or performed a search on that folder?

I suppose that serializeToStream will throw an exception if the disk is full. Then you just need to save to a different filename, and after it is on disk, replace the files.

> I would have expected that moving config.xml out of the way would regenerate it,
This is most definitely not true. This file is the primary/only source of some information, it cannot be recreated when missing.

It could have scanned the folder for all the scripts lying there. In fact, I ended up creating a script to make a basic config.xml frem the contents of gm_scripts folder.

> I didn't change any script, so there was no reason for greasemonkey to modify the file
A rather wide variety of conditions will trigger saving this file; as mentioned it stores a lot of things like enabled/disabled status of each script.

I didn't enable or disable a script in that browser session.

If the disk is full, not saving the disabling of a script is acceptable. Deleting your scripts is a bug.
(Ideally the user would get an alert explaining that it couldn't be saved, but that would break the save delay, just a silent fallback to the last good condition would be enough)

[johan]

I can confirm and verify this issue; it shot my config.xml too some months back (which gave me a notable nudge into trying to use Chrome as my main browser and see how that worked out).

When it hits you, it's a severe enough issue (severity in proportion to how much you had customized, say, your @include:s, and other metadata only available in config.xml) to impact hard, especially for all the 99.9+% of people who are not deeply into the inner guts of the format and could rework one that somewhat works from the data still available in the files and sub-directories of the gm_scripts directory.

Doing something (and I'm not sure quite what, yet) about this bug might be a decent "getting back into GM activity" kind of project for me, because I've been rather out of the loop ever since.

Of greater importance to myself about the solution (or mitigation; whatever it might be), is that I want to come up with something that won't automatically rot over ongoing evolution of Greasemonkey because the situation in which the bug hits you so rarely happens in typical installations.

Which might be something like each config.xml file write becomes a delete_backup + rename_config_to_backup + write_config and each read verifies presence of a trailing </UserScriptConfig> and falls back to reading the backup, when it fails.

And maybe a separate non-xpi-shipped tool people hit by this issue can use to piece together salvageable parts (with a lot of guessing about the lost details; assumptions like "make all installed scripts enabled") of their lost configuration from the spoils of a 1301-neutered gm_scripts tree.

[Martii]

This would seem to be a nsiFile issue for Moz perhaps. Error checking is a nice feature in some cases but may slow down execution for those who do have plenty of space. If the contents of the gm_scripts folder does get hosed it would be nice to have a backup for those users that don't already have one.

About the only recovery I can think of is to free up some space by whatever means... GM can refuse to alter/install a script if a low condition is found but again and extra conditionals may slow down that process.

±0

[LilDevil]

Error checking ... may slow down execution for those who do have plenty of space.
and
GM can refuse ... if a low condition is found but again [any] extra conditionals may slow down that process.

Modern disks are extremely fast and with the caching involved I can't imagine the extra delay imposed by the delete-rename-write process suggested by johan would amount to more than a 50 ms increase in time. Even if it was 10 times that, you wouldn't notice it.

[Martii]

Modern disks are extremely fast and with the caching involved

Modern HDDs wouldn't be running out of space ;)

Anyhow... perhaps a preallocation of the necessary file space would be okay but checking free space is something that should generally be avoided.

[kiranbk7]

I have started using portable firefox since last year.
I have this problem more often.I usually carry ffx for i am working on multiple machines an virtual machines.
I figured out to have a backup of the config.xml file in my mail.

The issue might be due to improper shutdown / termination of firefox.
however, good to have the file in my mail as backup .