View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0013452||Scribus||General||public||2015-10-22 11:59||2016-03-22 15:39|
|Target Version||1.5.2||Fixed in Version||1.5.2.svn|
|Summary||0013452: Can not open ".autosave" file: "is not in an acceptable format"|
|Description||Tying to open a .autosave file fails with error message "is not in an acceptable format".|
|Steps To Reproduce||- Create some document in Scribus|
- cp Document-1.sla Document-1.sla.autosave
- scribus --lang en Document-1.sla.autosave
Enjoy error message: "Document-1.sla.autosave is not in an acceptable format".
|Additional Information||Looks as if Scribus is looking at the filename, which is a bad thing anyway.|
|Tags||No tags attached.|
|related to||0013414||closed||cbradney||[CLI] --lang issues|
|related to||0013415||closed||cbradney||[CLI] Changing multiple flag rules|
|related to||0013413||closed||cbradney||[CLI] Error-message-wrong-and-too-verbose|
|related to||0013408||closed||cbradney||[CLI] --prefs option without provided file causes crash|
|has duplicate||0013482||closed||jghali||Scribus must not look at the file-extension when opening a scribus-file|
|related to||0008788||closed||fschmid||Automatic recovery|
|child of||0013584||acknowledged||Metabug: AutoSave & AutoRecover|
It works, the --lang flag is what's killing it.
$ /path/to/Scribus -l en ~/Desktop/Document-1.sla.autosave.sla
||This ticket brings up Juraj's patches. I've added them|
1) Your example is testing something *different*. Your file has
extension `.sla`, while I'm talking about `.sla.autosave'
2) This error occurs even without `--lang` option. I used that only to
get the error message in English.
you have to rename the file into .sla to open it.
it would be nice if scribus would not (only) rely on the extension to check if the file is what the extension says (this is mostly important for images)
||@ale: This is exactly what this bug-report is about.|
good points. thanks for pointing that out.
actually, i've been thinking about the autosave feature a bunch lately. I think this is a direction development should focus on in more depth. Especially given the number of crash bugs we've found and from personal experience, how many hours of work I've lost collectively discovering triggering known or unknown crash bugs while not saving my work in time.
For example, LibreOffice has a something akin to a Crash Restore wizard menu that comes up if it finds a file that was a result of a crash. VIM is another program that comes to mind that handles crashing restores really well. I think Scribus should have a very good mechanism to help people recover their work especially given how it crashes at times.
sorry htgoebel, i missed that line where it was written... since the discussion was going in every direction :-)
(i mean: what is the relationship with running scribus from the terminal? or with autosaving the files?)
can i suggest you that we close this ticket and you open one where you aks for scribus not (only) looking at the extension for detecting the file type (this means, in my eyes, that scribus first looks at the extension, but if an error occurs while reading the file, it should try other ways to detect the file's type)
||New ticket: http://bugs.scribus.net/view.php?id=13482|
||No need to create a new issue for something which is a direct consequence of an already existing issue.|
||KISS : rather than 'filename.sla.autosave', autosaved file could be named 'filename.autosave.sla'.|
I like the KISS method but your solution raises a question: How would a mechanism for the future Automatic Recovery function (0008788) recognize an .autosave. file ? Would it just scan for
\.autosave\.in a filename within said directory ?
Yes possibily. In case some automatic recovery function would propose to reeover these autosaved files and not some other specific autosaved files, then looking for autosave.sla files is as simple as looking for .sla.autosave files. But that's another issue.
Other possible : autosaving could give a version number. Begin with filenumber.autosave1.sla then autosave2.sla etc (and optionnaly clean older versions). Autorecovery should then look for \.autosave([0-9]+)?\.sla (But that's another issue)
||Confirmed fix by fschmid in either r21079 or r21083|
|2015-10-22 11:59||htgoebel||New Issue|
|2015-10-23 10:14||jghali||Priority||high => normal|
|2015-10-29 04:43||Kunda||Note Added: 0037075|
|2015-10-29 04:43||Kunda||Relationship added||related to 0013414|
|2015-10-29 04:44||Kunda||Relationship added||related to 0013415|
|2015-10-29 04:44||Kunda||Relationship added||related to 0013413|
|2015-10-29 04:44||Kunda||Relationship added||related to 0013408|
|2015-10-29 04:46||Kunda||Note Added: 0037077|
|2015-10-29 08:02||htgoebel||Note Added: 0037087|
|2015-10-29 11:19||ale||Note Added: 0037091|
|2015-10-29 11:43||htgoebel||Note Added: 0037092|
|2015-10-29 11:54||Kunda||Note Added: 0037093|
|2015-10-29 12:12||ale||Note Added: 0037095|
|2015-10-29 12:26||htgoebel||Note Added: 0037098|
|2015-10-29 13:06||jghali||Relationship added||has duplicate 0013482|
|2015-10-29 13:07||jghali||Note Added: 0037100|
|2015-11-19 02:10||Kunda||Relationship added||related to 0008788|
|2015-12-02 12:39||Kunda||Relationship added||child of 0013584|
|2015-12-02 16:14||JLuc||Note Added: 0037795|
|2015-12-02 16:49||Kunda||Note Added: 0037798|
|2015-12-02 16:49||Kunda||Note Edited: 0037798|
|2015-12-03 10:03||JLuc||Note Added: 0037805|
|2016-03-12 19:55||fschmid||Status||new => resolved|
|2016-03-12 19:55||fschmid||Fixed in Version||=> 1.5.2.svn|
|2016-03-12 19:55||fschmid||Resolution||open => fixed|
|2016-03-12 19:55||fschmid||Assigned To||=> fschmid|
|2016-03-14 06:42||Kunda||Note Added: 0039157|
|2016-03-15 20:02||fschmid||Target Version||=> 1.5.2|
|2016-03-22 15:39||Kunda||Status||resolved => closed|