#3754 5.0pre1 does not create backups on exit


Platforms: Windows XP SP3 & Windows 7 SP1 xp64

java Version: 1.7.0-09

Steps to reproduce:
1) Install a clean copy of 5.0pre1 with no plugins other than those that come with 5.0pre1.
2) Use the default settings for backups.
3) Edit a text file.
4) Save changes and exit jEdit.

Expected result: A backup copy of the text file in the directory containing the original text file.
Actual result: No backup copy.

I also found this behavior on 5.0pre2 and the most recent nightly build.


  • I tried to reproduce with most recent 5.0 and 5.1, but each time I was getting a backup on first save. It was on LInux with Java 6.

  • jrs40

    All this tells me is that 5.0pre1 is working under a Linux System with Java 6. I do not have access to Linux. The idea of editing Windows files on a Linux System with 5.0pre1 and then porting back to Windows seems a little nonsensical to me.

    Also, the current Stable Version 4.5.1 DOES create backups on exit on Windows XP SP3 and Windows 7 SP1 x64 under Java 1.7.0-09. This would indicate to me that there is something odd on the Java Code within 5.0pre1 that is causing this weird behavior.

  • Jrs, you don't have to use Linux and we will surely test on Windows too, but please allow me to leave some information for other developers.

  • jrs40

    My apologies. I did not mean to be confrontational since I forgot this is a OPEN FORUM and my comments will be see throughout the entire jEdit Community.

  • Steve

    I concur this is a problem with 5.1pre1 daily. With max_backups=1, backup_suffix=~, and backup_on_every_save=TRUE, there appear to be no backup files at all.

  • Steve

    Sorry, Win 7, Oracle Corporation Java 1.7.0_07

    • priority: 5 --> 7
    • assigned_to: nobody --> jarekczek
  • Confirmed on Windows with java 6. Seems to be a deal with a colon. There is also accompanying log message:
    07:43:22 [jEdit Worker #3] [warning] VFS: Backup of file C:\Temp\1\ab failed. Directory C_\Temp\1 do
    es not exist.

    Workaround: use a dedicated backup directory.

    Jrs, thanks for accurate and early bug report.

  • I had to reconsider backup file-naming strategy. It must be slightly different for local files and for remote ones. I think the attached patch is ok, but please give me 3 days for testins.

  • patch

    • status: open --> closed-fixed