What about http://doc.qt.io/qt-5/qstorageinfo.html#fileSystemType?

Uses statfs internally, on both platforms:

void QStorageInfoPrivate::retrieveVolumeInfo()
{
    QT_STATFSBUF statfs_buf;
    int result;
    EINTR_LOOP(result, QT_STATFS(QFile::encodeName(rootPath).constData(), &statfs_buf));
    if (result == 0) {
        valid = true;
        ready = true;

#if defined(Q_OS_INTEGRITY) || (defined(Q_OS_BSD4) && !defined(Q_OS_NETBSD))
        bytesTotal = statfs_buf.f_blocks * statfs_buf.f_bsize;
        bytesFree = statfs_buf.f_bfree * statfs_buf.f_bsize;
        bytesAvailable = statfs_buf.f_bavail * statfs_buf.f_bsize;
#else
        bytesTotal = statfs_buf.f_blocks * statfs_buf.f_frsize;
        bytesFree = statfs_buf.f_bfree * statfs_buf.f_frsize;
        bytesAvailable = statfs_buf.f_bavail * statfs_buf.f_frsize;
#endif
        blockSize = statfs_buf.f_bsize;
#if defined(Q_OS_ANDROID) || defined(Q_OS_BSD4) || defined(Q_OS_INTEGRITY)
#if defined(_STATFS_F_FLAGS)
        readOnly = (statfs_buf.f_flags & ST_RDONLY) != 0;
#endif
#else
        readOnly = (statfs_buf.f_flag & ST_RDONLY) != 0;
#endif
    }
}

//...

inline QByteArray QStorageIterator::fileSystemType() const
{
    return QByteArray(stat_buf[currentIndex].f_fstypename);
}

Hm, QStorageInfo does not seem to return anything sensible on FreeBSD:

""
name: ""
fileSystemType: ""
size: 0 MB
availableSize: 0 MB

This is the output from the QStorageInfo::root() example.

Okay, then maybe support for the current FreeBSD version is not implemented? I have no idea about FreeBSD, to be honest. But it looks like using this API, and implementing the proper support in QStorageInfo internals would be the appropriate place.

Anyhow, if Qt support is lacking, this patch here makes sense then -- at least the hunks for FreeBSD. I'll let others review this patch in detail.

Ok, I think I found the issue in QStorageInfo -- it calls getmntinfo() with flags=0 [1] . Instead one of the valid arguments 1-4 [2].

[1] https://github.com/qt/qtbase/blob/dev/src/corelib/io/qstorageinfo_unix.cpp#L199
[2] https://svnweb.freebsd.org/base/head/sys/sys/mount.h?revision=318736&view=markup#l441

So this patch looks ready to land to me: it simplifies the code, defers fstype-detection to QStorageInfo (for FreeBSD, we should fix the original issue there), and is otherwise non-intrusive.

Add reviewers who have commented, or who have committed to baloo recently.

The whole function as currently used is pointless.

Currently, it sets the NO_COW flag on BTRFS, but this is insufficient:

• XFS - https://lwn.net/Articles/747633/
• F2FS
• Hammer2 ?

At least on Linux, the correct thing is to *try* to set the no_cow flag, and silently ignore any EOPNOTSUPP errors.

Thats what I get on Linux for:

• File without permission to write: ioctl(3, FS_IOC_SETFLAGS, 0x7ffee879084c) = -1 EPERM (Operation not permitted)
• On an old XFS: ioctl(3, FS_IOC_SETFLAGS, 0x7fff8e52467c) = -1 EOPNOTSUPP (Operation not supported)
• BTRFS: ioctl(3, FS_IOC_SETFLAGS, 0x7fff06817a2c) = 0

This way the code is future proof even when a new FS appears or an old one gains new features.

The question is mostly: does the existing (complicated) code do anything that QStorageInfo doesn't? Because switching to QStorageInfo gives us the functionality on FreeBSD for free (even if it's not useful because we'll never have btrfs).

In D5784#243432, @adridg wrote:

The question is mostly: does the existing (complicated) code do anything that QStorageInfo doesn't? Because switching to QStorageInfo gives us the functionality on FreeBSD for free (even if it's not useful because we'll never have btrfs).

My opinion is to scrap the function completely, on *BSD and on Linux. Iff there ever is a need, one can add it back, or just call QStorageInfo directly wherever it is used.

See D12136

Given the other reviews (which just drop this function), this one should be abandoned. tcberner@?