PreviousNextTracker indexSee it online !

(121/231) 3389945 - edited file truncated after character encoding problems

If one tries to save a file with characters not belonging to chosen encoding, he gets an error message:

Cannot save: Failed to encode the character

Is it necessary to truncate the file at this moment? I switched off all backup helpers because I think I can take care of my files myself and don't need an assist in this. But it seems I need to protect my files from jEdit itself. Ok, jEdit is still being developed, I understand. Ignore this remark if you intend to fix the issue I had.

When I had problems with saving mentioned file I decided to reloaded it. Oops. Maybe a warning should appear when user tries to reload an empty file. It would be a good assecuration for similar cases.

jEdit 4.4.1.
Steps to reproduce:
0. disable two-stage save, set max number of backups to 0 (in saving & backup opts)
1. create new file, choose buffer encoding us-ascii
2. type some characters, save
3. add an international character, like ą
4. try to save, see the file gets truncated

Submitted jarekczek - 2011-08-11 - 08:30:50z Assigned k_satoda
Priority 3 Category None
Status Open Group None
Resolution Invalid Visibility No


2011-08-11 - 17:14:54z
> Is it necessary to truncate the file at this moment?

It seems necessary under settings where two stage save and backup are
both disabled. If you expect any other good bahavior, please describe

> Maybe a warning should appear when user tries to reload an empty file.

jEdit shows a warning when a dirty buffer is going to be reloeded.
I think that warning is enough for this case because the buffer is kept
dirty if a save request failed.
2011-08-13 - 07:00:08z
Pending, because nothing can be done without clarification of expected
2011-08-14 - 08:55:32z

1. truncating

The file should not be truncated. The exception message is clear enough to understand the file could not be saved. So I expect the old version of file to remain. That's from user point of view.

From programmers point of view I think the file should be checked against encoding problems before starting i/o operations.

2. warning on reload empty file

If something wrong and unexpected happens there is an empty file on disk, while the user, say I, thinks the old version is kept. So if press "reload" I expect to get the old file version, not to loose the file completety. To prevent such unexpected accidents it would be enough to give just one warning that "you try to reload an empty file". I can't imagine a situation where user really wants to reload an empty file. It rather denotes a serious error happened and the warning seems necessary to me.
2011-08-22 - 17:12:51z
Thank you for the clarification.

> 1. truncating

If you expect the old version to remain on failure, two-stage save is
likely the best solution, isn't it?

"Checking before I/O" maybe another solution, but it is suboptimal
(doubles the cost of encoding operation on normal case), and possible on
user side by a macro or a plugin. Thus, I don't want it as a core

> 2. warning on reload empty file

I think that such assumption "empty file indicates something wrong
happened" is not so general that a text editor can assume. I can imagine
some false positive if jEdit had such a warning. For example, reloading
a job list, error list, etc which is likely empty as usual.

I remember the following feature request, as a hopefully better solution
for your problem.
Undo "File reload" action
2011-08-24 - 08:49:05z
Let's go back to the roots. What I do is:

1. disable two-stage save, set max number of backups to 0 (in saving & backup opts)
2. open an important file using encoding us-ascii
3. add an international character, like ą
4. try to save
5. reload - get a warning, but I know the buffer is dirty, so I reload thinking I'm reloading the old version, but I get an empty file

The result is I loose an important file. Because I did nothing silly a good editor should not destroy the file.

The last answer to "File unload feature request", by shlomy, dated 2010-01-03, is negative to this idea. And I agree with it. Since no one replied to it, the idea is dead and won't be implemented. My solution to current problem is less expensive. No memory cost, and in worst case time cost of about 30% saving time (when a file is too big to fit in memory).

If "Checking before I/O" is still in play, then it may be done conditionally. When two-stage save is disabled.

The priority of this problem is not high (I changed it to 3), but I think the discussion should be finished with a reasonable solution.
2011-08-24 - 15:16:39z
Now I propose another solution:
Arrange "Cannot save" message so that it clearly shows the possibility
of file truncation if two-stage save was disabled, and recommends
two-stage save and/or backup options.

I think this can prevent "reload thinking I'm reloading the old version"
after the error was shown. It also covers the case when the file is
truncated at the middle (file is not empty, but incomplete), and more
cases of many other errors.
2011-08-25 - 07:10:46z
The identical idea came to me last evening :)