FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Fri May 14, 2021 07:27



Post new topic Reply to topic  [ 3 posts ] 
Storing permissions metadata in .NTFS-3G/ 
Author Message

Joined: Sat Aug 06, 2011 13:19
Posts: 4
Post Storing permissions metadata in .NTFS-3G/
Hello,

there are times when ntfs is used despite its discordance with Unix systems, because of its portability (i.e. support in Windows).
The main problem with NTFS when storage isn't shared across many users is IMO executable bit. It's a PITA. Personally I use metastore (which I had to fix to support traversing .git directories), but it's an overkill and I still cannot work directly on NTFS, so it's double overkill (but better than nothing).

fmask=133 is simply unacceptable.

Please consider adding an option (store_perms?) that would preallocate map (inode no -> perms) for all current and possible future inodes. This file would be big (12bit * DISK_SIZE/CLUSTER_SIZE, so typically ~= DISK_SIZE/2730) but it would make lives easier, perfectly repaying for less than 0.04% space loss. It could be called .NTFS-3G/FilePermsMapping and be allocated as continuous area of partition for better performance. Obviously by default executable bit wouldn't be set for any file that was already present in NTFS volume before turning on such option

It could be also simplified (store_exec?). You could store only executable bit (file would be 12 times smaller than the one for full perms) and just apply it for all (i.e. user, group, other, unless mask disallows particular combination) if it's present. It's not as flexible as above idea, but it would still greatly improve NTFS usability in Linux.

Regards,
Przemoc

P.S. I guess it could be work arounded by using some "transparent" filesystem that would handle appropriately permission getting/setting and everything else would be forwarded to the base filesystem. I've never programmed in fuse, but I guess this design should be possible. If you're aware of fuse limitations, please tell whether such proxy filesystem on-top-of normal filesystem is possible and if not, what is the closest solution that would allow implementing this idea?


Wed Feb 22, 2012 02:30
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Storing permissions metadata in .NTFS-3G/
Hi,

Quote:
The main problem with NTFS when storage isn't shared across many users is IMO executable bit.

What is the problem you are facing ?
Quote:
fmask=133 is simply unacceptable.

Posix ACLs are more powerful to manage complex situations.

Quote:
P.S. I guess it could be work arounded by using some "transparent" filesystem that would handle appropriately permission getting/setting and everything else would be forwarded to the base filesystem.

This is a good way to manage special needs ("cascading file system").

Regards

Jean-Pierre


Wed Feb 22, 2012 14:50
Profile

Joined: Sat Aug 06, 2011 13:19
Posts: 4
Post Re: Storing permissions metadata in .NTFS-3G/
Sorry for late reply. :)

jpa wrote:
Quote:
The main problem with NTFS when storage isn't shared across many users is IMO executable bit.

What is the problem you are facing ?
Quote:
fmask=133 is simply unacceptable.

Posix ACLs are more powerful to manage complex situations.


My problem in getting Posix ACLs to work (I tried them before asking the question) was lack of group mapping. Yet I think it should still work in such case.

In the end I mapped my personal Linux group to Users group (-513), but it works good only for one-man's files.


Sun Aug 12, 2012 19:19
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.