Enhancement: Support Windows filesystem attributes

[jmixton]

Windows has file attributes, e.g. hidden or system, for VFAT, NTFS and exFAT.

With VFAT and NTFS they can be accessed (more or less easily) from Linux.

For NTFS getfattr seems to do the trick:

box:~ # getfattr -R --no-dereference -e hex -n system.ntfs_attrib_be /mnt
# file: mnt
system.ntfs_attrib_be=0x00000036

# file: mnt/file1
system.ntfs_attrib_be=0x00000022

# file: mnt/file2
system.ntfs_attrib_be=0x00000020

For VFAT one can probably hack something together with mtools.

Searching through the exFAT code, however, I didn't find any mention of support for Windows attributes.

Would it be possible to add support for this to fuse-exfat?

[relan]

Searching through the exFAT code, however, I didn't find any mention of support for Windows attributes.

Right, fuse-exfat does not support manipulations with those attributes.

Would it be possible to add support for this to fuse-exfat?

I see no problem here. FUSE supports extended attributes (getxattr, setxattr and listxattr), so implementing appropriate callbacks will do the trick.

[nemonein]

I don't know that it's related this, but I have similar issue. I'm using Ubuntu 16.04, and exfat-fuse.

Every file and directory in exFat(formatted in MS Windows 10) has 700 permission, using exfat-fuse. If I create a file or directory in exFat on Linux, it has 700 too, regardless of whether it's file or directory.

Consequently, if I copy files from exFat drive to Linux file systems(ext4 and Btrfs), the permission is always set to 700 regardless of the file/directory type. Directories are set to 700 and even non executable files are set to 700 too.

It is sometimes annoying, and I had to change the permission manually. I hope there's way to set the permission to follow the default umask of the Linux system, when I copy files.

[relan]

@nemonein, this issue is about FAT's attributes system and hidden.

Unix permissions are a different story. exFAT does not have any equivalent for them. But fuse-exfat supports fmask and dmask mount options, maybe they can solve your problem.

[nemonein]

@relan Thank you for you answer. However, the disk with exFat I'm using is usually a flash drive, and I mount it by file managers(Nautilus, Nemo, etc). I know how to mount disks and give options(by mount command or /etc/fstab) to them, but I have no idea how it works on file managers. I just googled it but I could not find the way..

Can you give me any clue? I really appreciate it.

[relan]

The last time I looked into automounting, default mount options were hardcoded into udisks.

To override defaults you can create an fstab entry or udev rule.

[nemonein]

@relan Thanks! I'll try to find a way or work around.

[dionorgua]

I'm kindly voting for at least read-only support of 'read-only' attribute. it's widely used by various dashcams to mark files as 'important' using dedicated button or shock sensor.

[relan]

@dionorgua, what do you expect fuse-exfat to do when it discovers a read-only file?

[dionorgua]

for vfat kernel just shows file without 'w' permission. And it's possible to change 'RO' flag using chmod

[natale-p]

@relan, I jump into the discussion by proposing the following. Is it possible to add, somewhere in the filesystem, a special byte for each file, indicating the corresponding Unix permission? It could also be another file. I imagine something like

$ cp file /mnt/drive/file [inside, the module is creating /mnt/drive/file and /mnt/drive/.file_permissions which contains the perm of file]

and then $ mv /mnt/drive/file /home/file [inside, the module is reading /mnt/drive/.file_permission and applying these permission to /home/file]

This would not be inter-operable since other exFat modules will interpret these new files as "real" novel files, but after all, if someone is doing a backup this could be a nice feature.

[relan]

Is it possible to add, somewhere in the filesystem, a special byte for each file, indicating the corresponding Unix permission?

Yes, in exFAT each file entry can have optional subentries. They should be ignored by implementations that don't understand them, but considering the quality of other exFAT implementations, I'd expect multiple issues with this.

It could also be another file.

That's possible, but will introduce significant overhead for various file operations.

[natale-p]

Yes, in exFAT each file entry can have optional subentries.

Do you mean the "Reserved" FileAttributes bits (http://www.ntfs.com/exfat-file-directory-entry.htm)?

If yes, these can be written with the callback setxattr, right?

Thank you!

[relan]

No, I mean entries that have bit 5 in their type field set. In fact, entries of type 0xe0-0xff can store arbitrary data. But if we collide with another exFAT implementation that also uses the same entry type for its own purposes, bad things may happen.

[eMPee584]

So there is no way to set the system and hidden attributes on exfat under linux at the moment? That kind of breaks our use scenario (live-system overlay for dual boot)..

[wjt]

At Endless OS Foundation we are building exFAT disk images, on Linux, for consumption on Windows. We found ourselves wanting to set the hidden flags on some files. I took the lazy option and wrote a separate tool to tweak file attributes, #163, rather than plumbing it through to xattrs.