"Reset to defaults" does not remove /root/.ssh directory


After using the GUI "Reset to defaults" button, I see that the .ssh directory has not been removed. Anyone know why not?

Snapshot of what I see before and after

root@OpenWrt:~# ls -alg .ssh
drwxr-xr-x 2 root 0 Jan 30 12:21 .
drwxr-xr-x 1 root 0 Apr 6 20:34 ..
-rw-r--r-- 1 root 393 Oct 5 2018 known_hosts
root@OpenWrt:~# md5sum .ssh/*
1fa7f98ec289bf1f83bca4f2a0104b5e .ssh/known_hosts

I looked at the code that runs, jffs2reset.c but I do not see anything problematic.

Is this intentional behaviour?


When I do "umount /overlay && jffs2reset && reboot" from the command line, the .ssh directory is fully removed.


I've seen vaguely similar things before. Perhaps it is that the file is open so that a "soft" reset (which I believe is a delete) can't remove them??


I also tried creating /root/.joe/jdjd and /root/thing/jdskjd
A reset leaves the file in ".joe" and gets rid of the file in "thing".
So the problem is with removing files in sub-directory which starts with DOT

1 Like
1 Like

Your link leads to somebody's own copy of four year old code from 2015 instead of the current version. There may not be that much relevant difference, but still it might be better to look at the actual source repo at https://git.openwrt.org/?p=project/fstools.git;a=tree . At least the overlay code has got lots of new commits since then.

As you have noticed, unmounting the overlay first has impact. When overlay is still mounted, the jffs2reset leads to file system based deletion action. When overlay is unmounted, the action is partition level operation.

Regarding the error itself, like vgaetera hinted, this behaviour may be due to musl wildcard path handling.

1 Like

I've added this to the bug tracker here

1 Like