How did a file overwrite a directory?

kc9udx

This is the scariest thing. NetBSD 10.1, i386. The drive is an SSD with FFS. I ls /root and the directory looked normal. Next I cp -a script /root and the directory /root was replaced with a file called /root, of which the contents were my script.

How is this possible?

rvp

kc9udx How is this possible?

Shouldn't happen- - unless the dir. got deleted in between...

Run a fsck -f

kc9udx

rvp that's what I told the owner to do. I hope to hear the results. But I don't really see how this could be a filesystem problem. I was the only one logged in, and if there was anything else running that could delete that directory it would be an amazing coincidence. I was reading and writing files on that directory before the incident. I've sure never encountered anything like this. I couldn't duplicate the results, of course.

I would assume it was some absent-minded mistake on my part if I hadn't immediately prior listed the contents of that directory.

kc9udx

Apparently fsck -f came up with nothing. This is going to bother me for a long time. But at least I won't forget that /root doesn't get backed up with /home 😐

kc9udx

And here is the scrollback buffer from the time of the incident.

No one else was logged in at the time. If there's something that I'm overlooking here please let me know. I'm surprised I specified /root rather than /root/ which I normally do. But I can't recall a time in sh where this was a problem.

rvp

kc9udx OK, I think I can tell you what happened:

qemu$ uname -a
NetBSD qemu.local 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

qemu$ cd /tmp

qemu$ ls -l /etc/motd
-rw-rw-r--  1 root  wheel  76 Dec 20 08:08 /etc/motd

qemu$ ln -sv ~ home
home -> /home/rvp

qemu$ ls -A /tmp/home
.cshrc   .login   .logout  .profile .shrc

qemu$ cp /etc/localtime home			# regular copy

qemu$ ls -A /tmp/home
.cshrc    .login    .logout   .profile  .shrc     localtime

qemu$ cp -a /etc/motd home			# "preserving" copy

qemu$ ls -l home				# boom! old file's gone
-rw-rw-r--  1 rvp  wheel  76 Dec 20 08:08 home

qemu$ ls -A ~
.cshrc    .login    .logout   .profile  .shrc     localtime

qemu$

Your /root must've been a symlink and you used cp -a to copy the file.

Regular cp would've worked, as you can see, but, cp -a overwrites the destination rather than following the symlink to the actual directory.

I would've said this was a bug (both GNU cp and FreeBSD's cp, work as you would expect it to), except, this seems to be a deliberate behaviour change on NetBSD. See the commit message here.

I thought the [ -H | -L | -P ] flags only applied to the source args--like it says in the GNU cp man-page--but, this hasn't been the case on NetBSD since 2006.

Feel free to file a PR, or discuss on tech-userlevel@. I can't find the discussion for this because the HTTP tech-userlevel list archive only goes back to ~2008.

Maybe NetBSD's cp should have a -T flag, like GNU's, for explicitly overwriting files?

kc9udx I'm surprised I specified /root rather than /root/ which I normally do. But I can't recall a time in sh where this was a problem.

And, this is why I always, always automatically tack-on a /. to the destination arg. if I mean it to be a directory:

$ cp -a script /root/.

kc9udx

I don't believe it could've been a symlink. Though it must've been; as that's the only way this makes sense. I'll have to see. If it is, not only will the original still be there, but in this case it would mean that it's also being backed up which would be good.

I like to think I always specify the trailing / but as you can see, clearly I don't always. I'll have to be more vigilant. I still use other systems where this is more detrimental.

rvp

kc9udx Though it must've been; as that's the only way this makes sense.

Yes.

kc9udx I like to think I always specify the trailing /

The . is needed too--that's what guarantees a directory.