Clojurians Log v2

I need a second opinion. I am almost done working on a file system utilities library. One issue I'm still considering:

(delete-tree root)
(delete-tree root {:keys [:follow-links], :as opts})
Deletes a file tree using walk-file-tree. If :follow-links is true
then both symlinks and their targets will be deleted.

I'm thinking of a recent event where someone accidentally erased his hard disk..., albeit not using this lib.

I would honour the original unix rm command, and only delete the symbolic link and not walk recursively down.

rm -rf * will deref the symbolic link and not go into the link and delete what is contained within there.

my 2 🪙`s :)

Do you or anyone else you know of have a use case that would require following symlinks and recursively delete the contents of target directories? I don't think I've ever wanted to do that and, as you suggest, it's an incredibly dangerous feature. My suggestion would be to not implement this feature. If any user of the library complains then they can write code themselves to follow links (and accept the risk that results from this).

yeah. an alternative could be to rename the option to :dangerously-follow-links, but yeah, one could just write their own function if they want this

I will remove the option

I guess @cdpjenkins raised the good question, will somebody one day need to do that? I must confess I don't imagine it. So do you imagine one, @borkdude, as you consider the option?

@caumond I have seen people make bash scripts for this, but I haven't had the need myself. I just added it because a lot of functions in java.nio already have this behavior

ok , so if you're not opiniated neither, (;p. Maybe behave like the example you found in java.nio would have been an option?

Agree with @cdpjenkins Remove the possibility to hang yourself with delete-tree, but leave enough rope for anyone really wanting to hang themselves

There is no delete-tree / rm -rf in java.nio directly so you have to make choices here. Making it the same as rm -rf makes sense, I'll just leave the option out

Thanks y'all!

late to the party, but keep in mind that symlinks are definitionally "soft" links if one wanted a hard link he would have created such a link in the first place

As the "recent case" who erased a PC's hard disk this way, I agree with the above. Do what rm does by default and remove only the link, and make it possible (if you really needed to) to follow the link.

There was some code I saw recently that would follow symlinks inside the tree you were deleting, but only just remove the link (and not follow) if it pointed outside of the tree. That, if it were the default behaviour, would have saved me too. Worth a thought.

That is the default behavior of rm -rf and also fs/delete-tree. Just released the lib. Many thanks all. It comes bundled with babashka 0.2.9, also just released.

For the curious, this is what I found after investigating the incident last week: I was rewriting my backup bash script in babashka. My work mac, for some reason having to do with corporate IT nonsense or ActiveDirectory or somesuch, has a symlink in the home directory (in /Users) of the form BBC Desktop -> /. (This probably should have been excluded from the rsync backups.) My old bash script, for various reasons, needs to rm -rf * some old back ups once in a while. Instead of calling rm through clojure.java.shell, I decided to write some very naive Clojure recursive function that walked the tree and deleted the files and directories. When it got to that symlink, it just followed it and start recursively deleting from / on the back up PC... Bye bye back up PC.

It had eaten through /etc and most of /usr when I discovered the issue and unplugged the external ssd drive with the backups. Otherwise, if I didn't blow the stack, it would have deleted the back ups too.

So the recent event was a good reason to not include the option in delete-tree then.

I've been working with some people on a project where I suggested for us to consult with a DBA (since I'm not one and I'm not that confident in my SQL-fu). The day of reckoning has come, the comments and suggestions started pouring in. "And since you need different classes in the application layer in either case, adding some extra checks when unserializing is trivial" - oh, this is not a good start. So far my proposal of a bunch of simple tables with constraints has been met with table inheritance and JSON fields with constraints in the application layer.

Given discussion on laptops a couple of days ago… I’ve been using M1 MacBook Pro for a couple of week.  In short, it’s amazing. IntelliJ/Cursive, shadow-cljs watch, kaocha watch, Fulcro RAD app running in browser.  Laptop stays cool, totally silent, and runs for hours with only 20-30% battery consumed.  So different than my Intel MBP, which would last for no more than 45m doing similar jobs! It’s a fantastic dev setup — I still use a 2019 15" MBP as my main desktop machine, but I’m finding that I like programming on the M1 MBP better. Even with only one screen! Strange side effect, though. My hands get sometimes painfully cold using it, because the aluminum case is a giant heat sink!!! https://twitter.com/RealGeneKim/status/1358476835315585024 One downside: there are no ARM JVM builds with JavaFX yet. So, I can’t use Reveal anymore, which is a bummer. (I am tempted to install an x86 JVM, but am irrationally afraid that I’ll screw up my working dev environment… 🙂

I'm glad to hear Apple's third chipset transition is going smoothly (although I can't imagine buying another Apple device at this point). I went through both of their earlier transitions (680x0 -> RISC -> Intel) and they seem to do a really good job.