Our team has two different people right now working on two different machines with two different versions (5.1.5 and 5.1.4 - the guy running 5.1.4 is upgrading today, we didn’t realize he was behind a version). Both machines are Windows 10.
Both guys finished working about the same time yesterday afternoon. This morning, both discovered that all .sch files were missing. The .sch-bak files remained. They were able to rename the .sch-bak (remove the -bak) and get things working again.
Has anyone experienced anything like this?
We use cloud-based network drive called Egnyte. But it’s incredibly unlikely that it would have gone on some rampage targeting .sch files and removed them. What’s weird though is that in the service Trash bin (which shows all files deleted on the entire drive), the .sch files don’t show up.
Something weird is going on. Any help to understand what might be going on would be great. Specifically, how KiCAD deals with the backup files - when it creates them, when it updates them, and if it ever deletes the original it the process (which wouldn’t make any sense).
I’d start with local backups such as git or a .zip on a USB stick, at least until this is resolved.
I have never read about KiCad deleting it’s own files.
Is this in any way repeatable (especially as it already appears to have happened on 2 PC’s)
What happened between “yesterday afternoon” and “this morning”?
Maybe you have some nightly automated processes running?
I’m currently working with Egnyte to understand why the .sch files aren’t showing up in the deleted files. And what deleted them - was it Egnyte or KiCad. I agree, it seems unlikely that KiCad would have deleted them. But equally unlikely that Egnyte would have.
There’s no nightly automated processes running - at least nothing that’s supposed to be or could be doing this to my knowledge.
I’ll report back. My post had two purposes: 1) to see if anyone else was experiencing the same thing, 2) if anyone happens to experience the same thing in the future, to provide some ideas/answers for them.
I don’t know in what timezone you’re living, but here it’s past regular working day time.
At least verify your files still exist after exiting KiCad and both before and after the “Egnyte” thing.
One interesting thing I’ve learned is that when KiCad saves a backup copy, a new original copy is created. I can’t tell exactly what’s going on, but it looks like in the Egnyte audit files, KiCad moves or copies the original to the backup file and then creates a new original file. This means that in the Egnyte file history, there is never more than a single revision for the original schematic file. But the backup file continues to accumulate revisions. I guess either way a revision history exists. It would be great if KiCad kept a stream/history of file versions.
I’m still trying to figure out how/why the backup files yesterday were made but the original schematic files were lost.
Are you familiar with inodes on linux/unix?
Very short said. the inode number is the “real” file name, and the “usal file name” is just a directory entry that points to the inode.
So I started a very simple empty project, and saved it a few times after trivial edits, and each time made a directory listing.
inode 168825529 alternates between the “asdf.sch” and “asdf.sch-bak” after each save. (oops, see comment below).
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 12K
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825527 -rw-rw-r-- 1 paul paul 72 Mar 19 00:24 asdf.sch
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 20K
168825530 -rw-rw-r-- 1 paul paul 519 Mar 19 00:24 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825529 -rw-rw-r-- 1 paul paul 457 Mar 19 00:24 asdf.sch
168825527 -rw-rw-r-- 1 paul paul 72 Mar 19 00:24 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 20K
168825530 -rw-rw-r-- 1 paul paul 797 Mar 19 00:25 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825527 -rw-rw-r-- 1 paul paul 690 Mar 19 00:25 asdf.sch
168825529 -rw-rw-r-- 1 paul paul 457 Mar 19 00:24 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 20K
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:26 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825529 -rw-rw-r-- 1 paul paul 958 Mar 19 00:26 asdf.sch
168825527 -rw-rw-r-- 1 paul paul 690 Mar 19 00:25 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 20K
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:31 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825527 -rw-rw-r-- 1 paul paul 958 Mar 19 00:31 asdf.sch
168825529 -rw-rw-r-- 1 paul paul 958 Mar 19 00:26 asdf.sch-bak
Note: I am not a KiCad developer and have no idea whatsoever if KiCad behaves differently in this regard on other os’es. As a general rule I do not like renaming files much, as it leads to weird behaviour when using hardlinks.
This alternating inode is misleading. I made a few hard links, (file names a001 through a005) and each time in between saved the schematic. It seems that each time “asdf.sch” is renamed to “asdf.sch-bak” and a new file with the name “asdf.sch” is created upon each save. The alternating inode numbers were probably because it was the first number available after the backup file got deleted.
paul@dualcore:~/projects/kicad/asdf$ ln asdf.sch a001
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 24K
168825527 -rw-rw-r-- 2 paul paul 958 Mar 19 00:53 a001
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:53 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825527 -rw-rw-r-- 2 paul paul 958 Mar 19 00:53 asdf.sch
168825533 -rw-rw-r-- 1 paul paul 958 Mar 19 00:51 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 24K
168825527 -rw-rw-r-- 2 paul paul 958 Mar 19 00:53 a001
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:54 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825529 -rw-rw-r-- 1 paul paul 958 Mar 19 00:54 asdf.sch
168825527 -rw-rw-r-- 2 paul paul 958 Mar 19 00:53 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ln asdf.sch a002
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 28K
168825527 -rw-rw-r-- 1 paul paul 958 Mar 19 00:53 a001
168825529 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 a002
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:54 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825531 -rw-rw-r-- 1 paul paul 958 Mar 19 00:54 asdf.sch
168825529 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ln asdf.sch a003
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 32K
168825527 -rw-rw-r-- 1 paul paul 958 Mar 19 00:53 a001
168825529 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 a002
168825531 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 a003
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:54 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825531 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 asdf.sch
168825529 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ln asdf.sch a004
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 36K
168825527 -rw-rw-r-- 1 paul paul 958 Mar 19 00:53 a001
168825529 -rw-rw-r-- 1 paul paul 958 Mar 19 00:54 a002
168825531 -rw-rw-r-- 3 paul paul 958 Mar 19 00:54 a003
168825531 -rw-rw-r-- 3 paul paul 958 Mar 19 00:54 a004
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:57 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825532 -rw-rw-r-- 1 paul paul 958 Mar 19 00:57 asdf.sch
168825531 -rw-rw-r-- 3 paul paul 958 Mar 19 00:54 asdf.sch-bak
paul@dualcore:~/projects/kicad/asdf$ ln asdf.sch a005
paul@dualcore:~/projects/kicad/asdf$ ls -hil
total 40K
168825527 -rw-rw-r-- 1 paul paul 958 Mar 19 00:53 a001
168825529 -rw-rw-r-- 1 paul paul 958 Mar 19 00:54 a002
168825531 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 a003
168825531 -rw-rw-r-- 2 paul paul 958 Mar 19 00:54 a004 #Goofed up, made link without saving.
168825532 -rw-rw-r-- 2 paul paul 958 Mar 19 00:57 a005
168825530 -rw-rw-r-- 1 paul paul 3,6K Mar 19 00:58 asdf-cache.lib
168825528 -rw-rw-r-- 1 paul paul 51 Mar 19 00:24 asdf.kicad_pcb
168822009 -rw-r–r-- 1 paul paul 688 Mar 19 00:24 asdf.pro
168825533 -rw-rw-r-- 1 paul paul 958 Mar 19 00:58 asdf.sch
168825532 -rw-rw-r-- 2 paul paul 958 Mar 19 00:57 asdf.sch-bak
@paulvdh - this is really great information! Thank you very much for taking the time to do this. This seems to correspond with what I’m seeing in Egynte. There are no file versions for the .sch files, but there are for the .sch-bak files.
I’m still investigating what exactly is going on here and will report what I find. Thanks again.