How does the Unix “fsck” differ from the Windows “chkdsk”

Fsck returns your filesystem to a consistent state. This is not necessarily the filesystem's “latest” state, because that state might have been lost in the crash. In fact, if there were half-written files at the time of the crash, then the filesystem was not left in a consistent state, and that is precisely what fsck is designed to repair. In other words, after running fsck, your filesystem is as up-to-date as it can get.

If your application requires feedback as to what is stored on the disk in case of a crash, you'll need to do more work than just writing to a file. You need to call sync, or better fsync, after a write operation to ensure that that particular write has been committed to the disk (but if you end up doing this a lot, your performance will drop down, and you'll want to switch to a database engine). You'll need a journaled filesystem configured for maximum crash survival (as opposed to maximum speed).

The property that an operation (such as a disk write) that has been performed cannot be undone (even in the event of a system crash) is called durability. It's one of the four fundamental properties of databases (ACID). If you need that property, read up on transactions.

Although filesystems are a kind of database, they're usually not designed to do well with respect to ACID properties: they have more emphasis on flexibility. You'll get better durability from a dedicated database engine. Then consider what happens in case your disk, and not your system crashes: for high durability, you also need replication.

NTFS has Windows ACEs. Unix uses "mode bits" on each file.

On NTFS, each file can have an owner, and zero or more Windows access control entries (ACEs). An ACE consists of a principal (users and groups are principals), a set of operations (Read, Write, Execute, etc.) and whether those operations are allowed or denied. Files can have many ACEs. Other objects in Windows other than files can have ACEs as well, such as registry entries, printer objects, and other things. All ACEs are taken into account when a file operation occurs. Deny takes precedence over allow.

Windows ACEs support inheritance where you can set an ACE for a directory and have it automatically propagate to lower level directories.

Files in Unix have an owning user (owner) and an owning group (owner-group). There are three fixed "principals" which are owner, members of the owning group, and everyone else (a.k.a world). For each principal there are three "bits" which cover read, write, and execute abilities. (these have different meanings for directories than files, see this). These bits determine who can perform what operations. This is called the file's mode and is built into the file (there are no separate ACEs).

Most of the time you are concerned with the "world" permissions, i.e. setting all three bits to 0 for "world" means no one who isn't the owner or group-owner can do anything with the file. Unix permissions only work on the filesystem, but since most objects appear as files you can use permissions to restrict access to disks, printers, etc. Unix permissions are simpler but more "coarse." Unix permissions do not support inheritance and will not affect lower level directories, with the exception of execute permission for directories (I think) which causes newly created files to assume permissions of the directory (but doesn't affect currently created files).

Traditionally Unix files have a single owner and a single owner-group. There are extensions to Linux that add ACEs to files in similar fashion to Windows.

Unix's advantage is only that a simpler system is usually easier to understand and secure, and speed since the filesystem doesn't have to fetch ACEs in addition to inodes when opening files.