The “four significant differences” make the question sound like a homework problem, but it’s still worth answering (particularly since I’ll almost certainly answer it in a way that is different from the textbook that enumerated the “four differences” expects :) **

So, here’s my “four significant differences between file systems and database engines”:

• Database engines organize data into groups of records. The specifics of the record structure depend on the Data model used by the database, but individual records are addressable. File systems manage files as byte sequences, but typically have no awareness of the contents of files beyond the byte level.
• The above records can be fetched and manipulated using some type of search criterion that is known and managed by the database engine. At a minimum, it’ll be Key–value pair structured, with “value” content being possibly opaque to the database itself, but of a specific size. If you give the DB engine a key and a record with that key exists, you’ll get the record back.
• The database engine has an application API that can insert, delete, update, and fetch individual records and possibly groups of records. A query language is nice, but it isn’t mandatory as there are many types of database engines that don’t use query languages. This application API need not be client-server - there are a number of application-resident data managers that are packaged as libraries that live inside an application’s address space - but the API itself does exist and is well-defined.
• The only way to access the database data is via the above API, or applications built “on top of” the API. Note that file systems also have an API, typically the classic open/close/read/write/seek API.

I’d also argue that a minimal database management system has the above properties. By this definition, something like Redis is a minimal database management system.

Notice that this doesn’t say anything about highly important stuff like Database transactions, specific Query languages, database security, recoverability or even physical storage (In-memory databases do exist and are highly useful for some types of applications, and if they have plenty of redundancy, are even quite reliable). These are all hugely important in many application domains, but are not integral to the basic definition of a database manager.

Also note that “DBMS” need not be a Relational database, as full-blown enterprise-grade “DBMSs” exist, such as Apache Cassandra and many others, that are not relational.

**: it is very rare that people outside academic environments talk about “N of this, M of that”, as such tight and countable formulations rarely exist in “the real world”. However, textbook writers need to organize concepts into tight, countable units for ease of teaching and examination, so they are prone to doing this sort of thing.