| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 07 Apr 2009 11:21:57 -0700 From: Andreas Dilger <adilger@....com> To: Jamie Lokier <jamie@...reable.org> Cc: Jeff Garzik <jeff@...zik.org>, Oleg Drokin <green@...uxhacker.ru>, linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org> Subject: Re: Attempt at "stat light" implementation On Apr 07, 2009 18:56 +0100, Jamie Lokier wrote: > Jeff Garzik wrote: > > Jamie Lokier wrote: > > >Once you have fine-grained selection of stat fields - it's natural to > > >ask why not allow _additional_ stat fields in an future-extensible > > >fashion? A few things would be handy sometimes, such as inode > > >generation number, modification generation number (to detect changes > > >across reboots), and extra flags indicating COW or other properties. > > > > That's quite an interesting thought... until you run out of flags, the > > stat structure becomes a bit more flexible. > > I suspect at least one other unix or unix-like OS has done this > already, and it might be worth copying the interface. But none come to > mind. There is one in OS/X called getattrlist, but it is quite complex and would require attribute handling wildly different than what the kernel and *nix applications are doing: http://www.manpagez.com/man/2/getattrlist/ Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists