April 2012 - Wine-Devel - list.winehq.org

Patches 85862 & 85862

by Christian Costa

What's wrong with these patches : - http://source.winehq.org/patches/data/85862 - http://source.winehq.org/patches/data/85862 There are marked as pending but can't see anything wrong. Maybe I'm missing something. Christian

April 30, 2012

Re: [1/3] d3dx9: Define DDS structures. (try 3)

by Stefan Dösinger

The patches look good to me. Am Sonntag, 29. April 2012, 21:43:08 schrieb Józef Kucia: > This patch series implements the DDS support for D3DXGetImageInfo functions. > > Try 2: Define pitch as LONG. > Try 3: Revert it back to DWORD. > --- > dlls/d3dx9_36/surface.c | 66 > ++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 65 > insertions(+), 1 deletions(-) > > diff --git a/dlls/d3dx9_36/surface.c b/dlls/d3dx9_36/surface.c > index 567282c..3319927 100644 > --- a/dlls/d3dx9_36/surface.c > +++ b/dlls/d3dx9_36/surface.c > @@ -28,9 +28,73 @@ WINE_DEFAULT_DEBUG_CHANNEL(d3dx); > > > /* Wine-specific WIC GUIDs */ > - > DEFINE_GUID(GUID_WineContainerFormatTga, > 0x0c44fda1,0xa5c5,0x4298,0x96,0x85,0x47,0x3f,0xc1,0x7c,0xd3,0x22); > > +/* dds_header.flags */ > +#define DDS_CAPS 0x1 > +#define DDS_HEIGHT 0x2 > +#define DDS_WIDTH 0x2 > +#define DDS_PITCH 0x8 > +#define DDS_PIXELFORMAT 0x1000 > +#define DDS_MIPMAPCOUNT 0x20000 > +#define DDS_LINEARSIZE 0x80000 > +#define DDS_DEPTH 0x800000 > + > +/* dds_header.caps */ > +#define DDS_CAPS_COMPLEX 0x8 > +#define DDS_CAPS_TEXTURE 0x1000 > +#define DDS_CAPS_MIPMAP 0x400000 > + > +/* dds_header.caps2 */ > +#define DDS_CAPS2_CUBEMAP 0x200 > +#define DDS_CAPS2_CUBEMAP_POSITIVEX 0x400 > +#define DDS_CAPS2_CUBEMAP_NEGATIVEX 0x800 > +#define DDS_CAPS2_CUBEMAP_POSITIVEY 0x1000 > +#define DDS_CAPS2_CUBEMAP_NEGATIVEY 0x2000 > +#define DDS_CAPS2_CUBEMAP_POSITIVEZ 0x4000 > +#define DDS_CAPS2_CUBEMAP_NEGATIVEZ 0x8000 > +#define DDS_CAPS2_VOLUME 0x200000 > + > +/* dds_pixel_format.flags */ > +#define DDS_PF_ALPHA 0x1 > +#define DDS_PF_ALPHA_ONLY 0x2 > +#define DDS_PF_FOURCC 0x4 > +#define DDS_PF_RGB 0x40 > +#define DDS_PF_YUV 0x200 > +#define DDS_PF_LUMINANCE 0x20000 > + > +struct dds_pixel_format > +{ > + DWORD size; > + DWORD flags; > + DWORD fourcc; > + DWORD bpp; > + DWORD rmask; > + DWORD gmask; > + DWORD bmask; > + DWORD amask; > +}; > + > +struct dds_header > +{ > + DWORD signature; > + DWORD size; > + DWORD flags; > + DWORD height; > + DWORD width; > + DWORD pitch_or_linear_size; > + DWORD depth; > + DWORD miplevels; > + DWORD reserved[11]; > + struct dds_pixel_format pixel_format; > + DWORD caps; > + DWORD caps2; > + DWORD caps3; > + DWORD caps4; > + DWORD reserved2; > +}; > + > + > /************************************************************ > * D3DXGetImageInfoFromFileInMemory > *

April 30, 2012

Re: wined3d: Fix build with MSVC (try 2).

by Stefan Dösinger

Am Montag, 30. April 2012, 15:26:30 schrieb Thomas Faber: > port sounds great - but (assuming there shouldn't be any "0x7fc00000" or > "#ifdef _MSC_VER" in the solution) the best I can come up with at the moment > is the following :| Alexandre prefers checks in configure that set macros like HAVE_INFINITY in config.h. For my own msvc builds I have a hand-written config.h file - I'm not sure if there's a way to tell configure running in mingw or cygwin to use msvc as the compiler.

April 30, 2012

Re: wined3d: Fix build with MSVC (try 2).

by Thomas Faber

On 2012-04-29 12:05, Stefan Dösinger wrote: > Am Samstag, 28. April 2012, 10:16:13 schrieb Thomas Faber: >> Apparently NAN and INFINITE are C99 as well (I should really get a >> version of the old standard instead of mostly reading C99 :|). >> >> How about a simple const variable that will trick MSVC, while not >> changing semantics. > How about a function in libs/port or a macro in one of its headers? I believe > the NAN/INFINITE issue is not specific to wined3d. > > With the const variable, msvc compiles the code, but still produces a warning. Ah, the warning appears only with optimization enabled, that's why I didn't notice. port sounds great - but (assuming there shouldn't be any "0x7fc00000" or "#ifdef _MSC_VER" in the solution) the best I can come up with at the moment is the following :| #ifndef INFINITY static float __infinity(int x) { const float zero = x ? 0.0f : 1.0f; return 1.0f / zero; } # define INFINITY __infinity(1) #endif #ifndef NAN static float __nan(int x) { const float zero = x ? 0.0f : 1.0f; return zero / zero; } # define NAN __nan(1) #endif

April 30, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Julius Schwartzenberg

Eric Pouech wrote: > Le 29/04/2012 22:44, Eric Pouech a écrit : >> for the devels having upgraded their boxes to ubuntu 12.04, here's a >> couple of stuff I had to do, especially to get 32bit wine compile >> This could be useful if you want to have a dual x86_64 : i386 setup >> >> this is an updated version to what I already sent to scott ritchie >> of course this is not a step by step installation > I forgot to mention that ubuntu devels did a crappy job in 12.04 > I'm really starting to get angry at their inability to take care of > upward compat in what they do Maybe looking at 'sudo apt-get build-dep wine' and the Wine packaging scripts will also reveal what's needed to build 32-bit Wine on Ubuntu 12.04 64-bit. In general the 12.04 release still has loads of bugs however. It seems the developers couldn't manage to look over all the reported bugs anymore before the release, but decided to release anyhow. They probably only focused on the crash bugs, because there are not many crashes, but many things do not work yet as they should. I expect 12.04.1 will contain a very significant amount of fixes. Julius

April 30, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by GOUJON Alexandre

On 04/29/2012 10:44 PM, Eric Pouech wrote: <snip> > Warning at compilation > ---------------------- > when compiling, some warnings still have to be worked upon > /home/eric/work/wine/dlls/winex11.drv/keyboard.c:1109:5: warning: > 'XKeycodeToKeysym' is deprecated (declared at > /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] > this one can be forgotten for now (it's just being marked deprecated in > precise, so warning doesn't come from misconfiguration) FYI, I asked it to be marked as deprecated in [1] when solving bug #21307 [2]. Now ([3] from [4]), wine uses XkbKeycodeToKeysym when available. --- [1] : https://bugs.freedesktop.org/show_bug.cgi?id=5349 [2] : http://bugs.winehq.org/show_bug.cgi?id=21307 [3] : http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/keyboard.… [4] : http://source.winehq.org/git/wine.git/commitdiff/a30b94651d9f01b4bfa9afd073…

April 30, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by GOUJON Alexandre

On 04/29/2012 10:44 PM, Eric Pouech wrote: > for the devels having upgraded their boxes to ubuntu 12.04, here's a > couple of stuff I had to do, especially to get 32bit wine compile That's funny because I just tried yesterday and filed [1] to see what developers think. They are aware of the issue but will need some time to fix it. What I discovered is that installing gcc:i386 on amd64 doesn't mean what we think. It replaces the (amd64) gcc and wants to remove gcc and build-esential (and others). What we want is gcc-multilib which provides libc6-dev-i386. The other way also exists with libc6-dev-amd64:i386 (compiling programs targeting amd64 from a i386 computer) For the other issues, I guess we'll have to file as many bug as packages which are not multiarch-able. (I don't know how to say it, hope you get the idea) Hope it helps --- [1] : https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/990982

April 30, 2012

Re: [1/2] gdi32: GetGlyphOutline should fail for a bitmap font.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > On Sat, Apr 28, 2012 at 05:52:13PM +0900, Dmitry Timoshkov wrote: > > --- > > dlls/gdi32/freetype.c | 6 ++++++ > > dlls/gdi32/tests/font.c | 17 ++++++++++++----- > > 2 files changed, 18 insertions(+), 5 deletions(-) > > This will break the display of bitmap fonts in winex11.drv . > > Do you have an app that depends on this? No, I have no an app that depends on this. I just tried to test bitmap font metrics with GetGlyphOutline since in Wine it's used to get metrics even for bitmaps. and found that it's supposed to fail. I guess that I resend the test without a fix then. -- Dmitry.

April 30, 2012

Re: [1/2] gdi32: GetGlyphOutline should fail for a bitmap font.

by Huw Davies

On Sat, Apr 28, 2012 at 05:52:13PM +0900, Dmitry Timoshkov wrote: > --- > dlls/gdi32/freetype.c | 6 ++++++ > dlls/gdi32/tests/font.c | 17 ++++++++++++----- > 2 files changed, 18 insertions(+), 5 deletions(-) This will break the display of bitmap fonts in winex11.drv . Do you have an app that depends on this? Huw.

April 30, 2012

Re: Ubuntu 12.04 (version#2, drop previous mail)

by Damjan Jovanovic

On Mon, Apr 30, 2012 at 10:37 AM, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> This is because you _cannot_ install the 32-bit -dev packages onto >> 12.04. It's not just symlinks that are missing, many of the header >> files are different between the arches. > I'm not sure this is a generic rule, and if it were, then exclusion > between i386 and x86_64 should be defined on most dev packages, and > it's not the case > also note, that in some cases, arch specific headers are moved to arch > dependent directories (e.g. jpeg, glib...), which should also parallel > install of multi-arch libs > in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least > >> Just do the chroot. You will save yourself so much grief and it will >> actually work. > if the ubuntu folks keep this state of mind, then they'll continue to sink > the best solution is then to pick up another distro > A+ +1. One of the reasons I stopped contributing to Wine is that it became too hard to set up 32 bit dev libraries on a 64 bit Ubuntu 11.10 system with its broken multiarch. I was hoping it would be fixed in 12.04, but if it's so broken now that we have to use a chroot, then I might as well use FreeBSD where chroot has always been the only way. Damjan Jovanovic

April 30, 2012

Re: Ubuntu 12.04 (version#2, drop previous mail)

by Eric Pouech

> This is because you _cannot_ install the 32-bit -dev packages onto > 12.04. It's not just symlinks that are missing, many of the header > files are different between the arches. I'm not sure this is a generic rule, and if it were, then exclusion between i386 and x86_64 should be defined on most dev packages, and it's not the case also note, that in some cases, arch specific headers are moved to arch dependent directories (e.g. jpeg, glib...), which should also parallel install of multi-arch libs in any case, the job by ubuntu folks in 12.04 done is crappy, to say the least > Just do the chroot. You will save yourself so much grief and it will > actually work. if the ubuntu folks keep this state of mind, then they'll continue to sink the best solution is then to pick up another distro A+ -- -- Eric Pouech

April 30, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Jerome Leclanche

On Sun, Apr 29, 2012 at 9:50 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > Le 29/04/2012 22:44, Eric Pouech a écrit : > > for the devels having upgraded their boxes to ubuntu 12.04, here's a >> couple of stuff I had to do, especially to get 32bit wine compile >> This could be useful if you want to have a dual x86_64 : i386 setup >> >> this is an updated version to what I already sent to scott ritchie >> of course this is not a step by step installation >> > I forgot to mention that ubuntu devels did a crappy job in 12.04 > I'm really starting to get angry at their inability to take care of upward > compat in what they do > > > A+ > > -- > Eric Pouech > "The problem with designing something completely foolproof is to > underestimate the ingenuity of a complete idiot." (Douglas Adams) > > I tried for ages to get multiarch compiling working in 12.04, in the end it was the last straw that made me switch to Arch Linux. Other than that, I did get some issues compiling with the newer libjpeg but I think it's been fixed since. J. Leclanche

April 29, 2012

Re: Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Eric Pouech

Le 29/04/2012 22:44, Eric Pouech a écrit : > for the devels having upgraded their boxes to ubuntu 12.04, here's a > couple of stuff I had to do, especially to get 32bit wine compile > This could be useful if you want to have a dual x86_64 : i386 setup > > this is an updated version to what I already sent to scott ritchie > of course this is not a step by step installation I forgot to mention that ubuntu devels did a crappy job in 12.04 I'm really starting to get angry at their inability to take care of upward compat in what they do A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 29, 2012

Fwd: Ubuntu 12.04 (version#2, drop previous mail)

by Eric Pouech

for the devels having upgraded their boxes to ubuntu 12.04, here's a couple of stuff I had to do, especially to get 32bit wine compile This could be useful if you want to have a dual x86_64 : i386 setup this is an updated version to what I already sent to scott ritchie of course this is not a step by step installation, just hints if you want to take that road (version #3) (I'm using a multiarch x86_64/i386) now wine compiles and runs in 32bit while compiled on 64bit machine here's the summary of the pain getting it right after upgrade in response to https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321 I was able to compile 32bit-wine on 64bit as I always, and without a chroot or anything similar Problem #1 ---------- an old (11.10 according to the dates) directory was left over after migration, whereas it should have been removed /usr/include/i386-linux-gnu Problem #2 ---------- a ton of symlinks are missing in /usr/lib/i386-linux-gnu for example [root:/usr/lib/i386-linux-gnu]# ls -l /usr/lib/i386-linux-gnu/libfree* lrwxrwxrwx 1 root root 20 avril 3 10:54 /usr/lib/i386-linux-gnu/libfreetype.so.6 -> libfreetype.so.6.8.0 -rw-r--r-- 1 root root 624084 avril 3 10:54 /usr/lib/i386-linux-gnu/libfreetype.so.6.8.0 and it misses lrwxrwxrwx 1 root root 16 avril 28 21:30 /usr/lib/i386-linux-gnu/libfreetype.so -> libfreetype.so.6 the same applies for a lot libraries libXcursor.so libXi.so libXxf86vm.so libxrandr.so libxinerama.so libxcomposite.so libGLU.so libdbus-1.so (libdbus-1.so lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu) libgnutls.so libsane.so libv4l1.so libgphoto2.so libgphoto2_port.so libgstreamer-0.10.so (***) libcapi20.so libcups.so libfontconfig.so libtiff.so libmpg123.so libopenal.so libxrender.so libGL.so (libGL.so is in mesa subdir!!!) libxml2.so libxslt.so libssl.so libcrypto.so libjpeg.so (***) libpng.so.0 (libpng12.so.0 lies in /lib/i386-linux-gnu, not /usr/lib/i386-linux-gnu) libXext.so the ones marked (***) means that the symlink is missing but it doesn't solve fully the issue from a wine perspective (see below) Problem #3 (jpeg) ----------------- Fails to open<jconfig.h>. which only lies in /usr/include/x86_64-linux-gnu/jconfig.h, and couldn't be accessed from 32bit build Creating the /usr/include/i386-linux-gnu/ directory and creating a symlink for jconfig.h to /usr/include/x86_64-linux-gnu/jconfig.h just works (I checked the contents of jconfig.h and it looks reasonable to do so) Problem #4 (gstreamer) ---------------------- it doesn't work as only /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h is installed (/usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h doesn't exist, dpkg -S doesn't find it) and /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h defines gint64 as long, which is correct on 64bit targets one wrong on 32 bit ones... one should craft a decent /usr/lib/i386-linux-gnu/glib-2.0/include/glibconfig.h, or grab one out of pure i386 install (I haven't had time to look further into those, my main interest was to have a 32bit setup up& running) List of potentially installed i386 packages ------------------------------------------- fixed by installing i386 packages (not exhaustive, unfortunately, as I didn't note all the :i386 packages I've manually installed) libldap2.so alternatively, if I do a [eric:~]$ dpkg -l | grep i386 | grep -- -dev ii libc6-dev-i386 2.15-0ubuntu10 Embedded GNU C Library: 32-bit development libraries for AMD64 ii libldap2-dev:i386 2.4.28-1.1ubuntu4 OpenLDAP development libraries ii libpthread-stubs0-dev:i386 0.3-3 pthread stubs not provided by native libc, development files ii libx11-dev:i386 2.1.4.99.1-0ubuntu2 X11 client-side library (development headers) ii libxau-dev:i386 1:1.0.6-4 X11 authorisation library (development headers) ii libxcb1-dev:i386 1.8.1-1 X C Binding, development files ii libxdmcp-dev:i386 1:1.1.0-4 X11 authorisation library (development headers) tends to ask for libc6-dev:i386, libldap2-dev:i386, libx11-dev:i386, libxau-dev:i386, libxcb1-dev:i386, libxdmcp-dev:i386 as dedicated installations of dev:i386 packages but strangely enough, when looking at details, libx11-dev (for example) cannot be installed with libx11-dev:i386 according to manifest, but I have both installed (and both install the same files in /usr/include for example) this looks very strange indeed List of stuff that won't work ----------------------------- won't be supported (just to note them, as those are the left overs from the configure failing list) compiled without multiarch support: libhal, libgsm Warning at compilation ---------------------- when compiling, some warnings still have to be worked upon /home/eric/work/wine/dlls/winex11.drv/keyboard.c:1109:5: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations] this one can be forgotten for now (it's just being marked deprecated in precise, so warning doesn't come from misconfiguration) debugging (32bit and 64bit) is broken ------------------------------------- the debugging is broken it turns out that ptrace and prctl (which had to be added in 11.10) work fine when tracing, only the first started process get correct pid out of wineserver in socket SCM_CREDENTIALS info. the later get 0 I tried to force the pid without requiring the recvmsg stuff and it works just fine I've not found yet the change that broke this more to come if get any futher on the remaining topics A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 29, 2012

Re: wined3d: Fix build with MSVC (try 2).

by Stefan Dösinger

Am Samstag, 28. April 2012, 10:16:13 schrieb Thomas Faber: > Apparently NAN and INFINITE are C99 as well (I should really get a > version of the old standard instead of mostly reading C99 :|). > > How about a simple const variable that will trick MSVC, while not > changing semantics. How about a function in libs/port or a macro in one of its headers? I believe the NAN/INFINITE issue is not specific to wined3d. With the const variable, msvc compiles the code, but still produces a warning.

April 29, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Fri, Apr 27, 2012 at 01:31:07PM -0600, Andreas Dilger wrote: > On 2012-04-27, at 7:13 AM, Dave Chinner wrote: > > Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined > > at the bottom of the file. > > > > Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly > > generic - they are for indicating that files are to be avoided for > > defrag or backup purposes, the prealloc bit indicates that fallocate > > has been used to reserve space on the inode (finding files that space > > can be punched out of safely), and so on. > > There is already the FS_NODUMP_FL in the standard FS_IOC_GETFLAGS ioctl > and I expect this to be in statxat() also. I forgot that was one of the generic flags :/ > In ext4 there was also an > EXT4_EOFBLOCKS_FL added for inodes with fallocate'd data beyond EOF, > but Eric thought it was a pain to maintain and it has been deprecated > in ext4 and e2fsprogs recently. I'd think that flag is more of a "filesystem implementation specific" flag than a general "this file contained persistent preallocation" flag, which is essentially what the XFS flag says. XFS uses in various ways to optimise extent management on the file (e.g. don't truncate extents past EOF when closing the file), but it is not specific to one particular aspect of the preallocation implementation. > >> OTOH, there's plenty of uncommitted space, so if we can condense > >> the hints down to something small, we could perhaps add it later - > >> but from your paragraph above, it doesn't sound like it'll be small. > > > > Allocation block size, minimum sane IO size (to avoid page cache RMW > > cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit), > > optimal IO size for bandwidth (e.g. stripe width). I don't think > > there's much more than that which will be really usable by > > applications. > > I think this is a minimal set that makes sense, and is manageable for > both the interface and for users. Even if it isn't 100% correct for > every file of every filesystem, it still makes sense for many systems. That's the aim, isn't it? To expose what is useful to the majority in a simple manner? > I'd suggest st_frsize (like BSD statvfs() f_frsize) would be the > minimum fragment or page size, st_iosize (BSD f_iosize) could be > the optimal IO size, and "st_stripesize" for the minimum preferred RAID/chunk size. Personally, I think those names are, well, terribly lacking in obviousness. Something more along the lines of: st_blksize - file block size st_alloc_blksize - allocation block size/alignment st_small_io_size - IO size/alignment that avoids filesystem/page cache RMW st_preferred_io_size - preferred IO size for general usage. st_large_io_size - IO size/alignment for high bandwidth sequential IO With the aim that applications tend to use st_preferred_io_size for all general IO (i.e. the default), st_small_io_size for small IO, IOPS intensive workloads, and st_large_io_size for writing large chunks of sequential data. > One could argue that "st_blksize" is used for the "optimal IO size" > on Linux today, but this is an overloaded term. It _appears_ to > represent the filesystem blocksize, which it usually is not, and on > BSD st_bsize means the minimum blocksize and has a confusingly > similar name. Since any application using this API needs to do some > extra coding already, we may as well give the structure members good > names that are not ambiguous. Well said - I couldn't have stated the case better myself. ;) Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 28, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Fri, Apr 27, 2012 at 7:38 PM, Dave Chinner <david(a)fromorbit.com> wrote: > preferred minimum IO size (mp->m_readio_log/mp->m_writeio_log) This discussion about i/o sizes is very interesting. For network file system (at least for SMB2 to all known servers, and for cifs mounts to Samba, but probably for recent NFS), ideal i/o sizes are often well over a megabyte ... but how to indicate that to the application... > That's why I'd prefer specific optimal IO hints - we don't have to > overload st_blksize with lots of meanings to pass what is relatively > trivial information back to the application. > > Cheers, > > Dave. > -- > Dave Chinner Yes. -- Thanks, Steve

April 28, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Thu, Apr 26, 2012 at 09:22:04PM -0600, Andreas Dilger wrote: > On 2012-04-26, at 7:06 PM, Dave Chinner wrote: > > On Thu, Apr 19, 2012 at 03:05:58PM +0100, David Howells wrote: > >> > >> Implement a pair of new system calls to provide extended and further extensible stat functions. > >> > >> The second of the associated patches is the main patch that provides these new system calls: > >> > >> ssize_t ret = xstat(int dfd, > >> const char *filename, > >> unsigned atflag, > >> unsigned mask, > >> struct xstat *buffer); > >> > >> ssize_t ret = fxstat(int fd, > >> unsigned atflag, > >> unsigned mask, > >> struct xstat *buffer); > >> > >> which are more fully documented in the first patch's description. > >> > >> These new stat functions provide a number of useful features, in summary: > >> > >> (1) More information: creation time, inode generation number, data > >> version number, flags/attributes. A subset of these is available > >> through a number of filesystems (CIFS, NFS, AFS, Ext4 and BTRFS). > > > > If we are adding per-inode flags, then what do we do with filesystem > > specific flags? e.g. XFS has quite a number of per-inode flags that > > don't align with any other filesystem (e.g. filestream allocator, > > real time file, behaviour inheritence flags, etc), but may be useful > > to retrieve in such a call. We currently have an ioctl to get that > > information from each inode. Have you thought about how to handle > > such flags? > > I'm sympathetic to your cause, but I don't want this to degrade into > the same morass that it did last time when every attribute under the > sun was added to the call. Understood, which is why I'm not asking for everything under the sun to be supported. I'm more interested in finding the useful subset of information that a typical application might make use of. > The intent is to replace the stat() call > with something that can avoid overhead on filesystems for which some > attributes are expensive, and that applications may not need. Some > common attributes were added that are used by multiple filesystems. > > If it is too filesystem-specific, and there is little possibility > that these attributes will be usable on other filesystems, then it > should remain a filesystem specific ioctl() call. Right, that's why I didn't mention the real-time bits, the filestream allocation bits, or other things that are tightly bound to the way XFS works.... > If you can make > a case that these attributes have value on a few other filesystems, > and applications are reasonably likely to be able to use them, and > their addition does not make the API overly complex, then suggest > away. Exactly my thoughts ;) > > Along the same lines, filesytsems can have different allocation > > constraints to IO the filesystem block size - ext4 with it's > > bigalloc hack, XFS with it's per-inode extent size hints and the > > realtime device, etc. Then there's optimal IO characteristics > > (e.g. geometery hints like stripe unit/stripe width for the > > allocation policy of that given file) that applications could use > > if they were present rather than having to expose them through > > ioctls that nobody even knows about... > > There is already "optimal IO size" that the application can use, > how do the geometry hints differ? Have a look at how XFS overloads stat.st_blksize depending on the filesystem and inode config. It's amazingly convoluted, and based on a combination of filesystem geometry, inode bits and mount options: xfs_vn_getattr() .... if (XFS_IS_REALTIME_INODE(ip)) { /* * If the file blocks are being allocated from a * realtime volume, then return the inode's realtime * extent size or the realtime volume's extent size. */ stat->blksize = xfs_get_extsz_hint(ip) << mp->m_sb.sb_blocklog; } else stat->blksize = xfs_preferred_iosize(mp); ...... xfs_extlen_t xfs_get_extsz_hint( struct xfs_inode *ip) { if ((ip->i_d.di_flags & XFS_DIFLAG_EXTSIZE) && ip->i_d.di_extsize) return ip->i_d.di_extsize; if (XFS_IS_REALTIME_INODE(ip)) return ip->i_mount->m_sb.sb_rextsize; return 0; } .... static inline unsigned long xfs_preferred_iosize(xfs_mount_t *mp) { if (mp->m_flags & XFS_MOUNT_COMPAT_IOSIZE) return PAGE_CACHE_SIZE; return (mp->m_swidth ? (mp->m_swidth << mp->m_sb.sb_blocklog) : ((mp->m_flags & XFS_MOUNT_DFLT_IOSIZE) ? (1 << (int)MAX(mp->m_readio_log, mp->m_writeio_log)) : PAGE_CACHE_SIZE)); } All of that can be exported as 4 parameters for normal files: allocation block size (extent size hint) minimum io size (PAGE_CACHE_SIZE) preferred minimum IO size (mp->m_readio_log/mp->m_writeio_log) best aligned IO size (stripe width) And for realtime files it's a bit different because of the block-based bitmap allocator it uses: allocation block size (extent size hint) minimum io size (PAGE_CACHE_SIZE) preferred minimum IO size (extent size hint) best aligned IO size (some multiple of extent size hint) > Userspace is able to handle > st_blksize of several MB in size without problems, and any sane > application will do the IO sized + aligned on multiples of this. Actually, some applications still have problems with that. That's the reason we only expose stripe widths in st_blksize when a mount option is set. Stripe widths are known to get into the tens of MB, and applications using st_blksize for memory allocation of IO buffers tend to get into trouble with those. That's why I'd prefer specific optimal IO hints - we don't have to overload st_blksize with lots of meanings to pass what is relatively trivial information back to the application. Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 28, 2012

Re: [PATCH 0/6] Extended file stat system call

by Paul Eggert

On 04/26/2012 11:25 AM, Roland McGrath wrote: > What I'd really prefer is a name that is less meaninglessly arcane, Since people are used to the string "stat", and since this is about getting related attributes, how about using the string "statr"? Thus "statrat" could be the syscall that acts like fstatat, but gets related attributes too. A bonus of this name is that a "stat rat" is slang for someone who loves looking at statistics, often sports statistics. Billy Beane is a stat rat. Someone who cares about files' statistics is also a stat rat. The "r" in "statrat" could stand for "related", or for "relevant", or for whatever you like.

April 27, 2012

Re: Wine developer example sessions?

by Dan Kegel

On Fri, Apr 27, 2012 at 1:35 PM, Lucas Zawacki <lfzawacki(a)gmail.com> wrote: > When I first started to learn about wine development I stumbled across > some examples exactly like these in the wine wiki. A quick search > reveals them (the first 3) > http://wiki.winehq.org/DeveloperExamples?action=fullsearch&context=180&valu… > > I myself like this aproach, it's a very useful form of documentation. Ah, thanks, I link to those now, and to a canned query for AF's excellent bug reports, from http://wiki.winehq.org/DeveloperExamples

April 27, 2012

Re: Wine developer example sessions?

by Lucas Zawacki

When I first started to learn about wine development I stumbled across some examples exactly like these in the wine wiki. A quick search reveals them (the first 3) http://wiki.winehq.org/DeveloperExamples?action=fullsearch&context=180&valu… I myself like this aproach, it's a very useful form of documentation.

April 27, 2012

Wine developer example sessions?

by Dan Kegel

I'm bringing a new intern up to speed, and while I was showing him how to diagnose one particular wine bug, I recorded the session on a web page, http://kegel.com/wine/bug30486.html It occurred to me that recorded sessions like that might be useful to other beginners (above and beyond the more structured wine developer doc), so I created http://wiki.winehq.org/DeveloperExamples and linked to it from there. Does that seem useful, and are there other tutorials that could be linked to?

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Andreas Dilger

On 2012-04-27, at 7:13 AM, Dave Chinner wrote: > Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined > at the bottom of the file. > > Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly > generic - they are for indicating that files are to be avoided for > defrag or backup purposes, the prealloc bit indicates that fallocate > has been used to reserve space on the inode (finding files that space > can be punched out of safely), and so on. There is already the FS_NODUMP_FL in the standard FS_IOC_GETFLAGS ioctl and I expect this to be in statxat() also. In ext4 there was also an EXT4_EOFBLOCKS_FL added for inodes with fallocate'd data beyond EOF, but Eric thought it was a pain to maintain and it has been deprecated in ext4 and e2fsprogs recently. > Currently these things are queried and manipulated by ioctls > (XFS_IOC_FSX[GS]ETATTR) along with extent size hints, project > quotas, etc. but I think there's some wider use for many of the > flags, which is why I was asking is there's any thought to this sort > of flag being exposed by the VFS. > > Historically the flags exposed by the VFS are those used by extN - I > see little reason why we should favour one filesystem's flags over > any others in an extended stat interface if they are generically > useful.... Sure, they started as ext4 flags because the "lsattr" and "chattr" tools were using this ioctl/flags, but have become more generic in recent years. FS_NOTAIL_FL was added for Reiserfs, and FS_NOCOW_FL was added for another filesystem (maybe Btrfs?). I'm not against adding more flags here that are generically useful, and recommended that statxat() have a 64-bit st_ioc_flags, since there are already 22 FS_*_FL flags defined today. >> Either you can add some of them to the ioc flags (which may be >> impractical, I grant you) or we'd have to add an arbitrary fs-type >> specific field and specify the host fs (the provision of which might >> not be a bad idea in and of itself) to tell userspace how to interpret them. > > Well, that's the complexity, isn't it. I have no good answer to > that... > >>> Along the same lines, filesytsems can have different allocation >>> constraints to IO the filesystem block size - ext4 with it's >>> bigalloc hack, XFS with it's per-inode extent size hints and the >>> realtime device, etc. Then there's optimal IO characteristics >>> (e.g. geometery hints like stripe unit/stripe width for the >>> allocation policy of that given file) that applications could >>> use if they were present rather than having to expose them >>> through ioctls that nobody even knows about... >> >> Yeah... Not representable by one number. You'd have to unset a >> flag to say you were providing this information. >> >> However, providing a whole bunch of hints about I/O characteristics >> is probably beyond this syscall - especially if it isn't constant >> over the length of a file. That's specialist knowledge that most >> applications don't need to know. >> Having a generic way to retrieve it, though, may be a good idea. > > We're continually talking about applications giving us usage hints > on what IO they are going to do so the storage can optimise the IO. > IO is still a GIGO problem, though, and the idea of geometry hints > is to enable us to tell the application to do well formed IO. i.e. > less garbage. > > XFS has ioctls to expose filesystem geometry, optimal IO sizes, the > alignment limits for direct IO, etc, and they are very useful to > applications that care about high performance IO. A lot of this can > be distilled down to a simple set of geometries, and generally > speaking they don't change mid way through a file.... > >> OTOH, there's plenty of uncommitted space, so if we can condense >> the hints down to something small, we could perhaps add it later - >> but from your paragraph above, it doesn't sound like it'll be small. > > Allocation block size, minimum sane IO size (to avoid page cache RMW > cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit), > optimal IO size for bandwidth (e.g. stripe width). I don't think > there's much more than that which will be really usable by > applications. I think this is a minimal set that makes sense, and is manageable for both the interface and for users. Even if it isn't 100% correct for every file of every filesystem, it still makes sense for many systems. I'd suggest st_frsize (like BSD statvfs() f_frsize) would be the minimum fragment or page size, st_iosize (BSD f_iosize) could be the optimal IO size, and "st_stripesize" for the minimum preferred RAID/chunk size. One could argue that "st_blksize" is used for the "optimal IO size" on Linux today, but this is an overloaded term. It _appears_ to represent the filesystem blocksize, which it usually is not, and on BSD st_bsize means the minimum blocksize and has a confusingly similar name. Since any application using this API needs to do some extra coding already, we may as well give the structure members good names that are not ambiguous. >>> Perhaps also exposing the project ID for quota purposes, like we >>> do UID and GID. That way we wouldn't need a filesystem specific >>> ioctl to read it.... >> >> Is this an XFS only thing? If so, can it be generalised? > > Right now it is, but there's been patches in the past to introduce > project quotas to ext4. That didn't go far because it was done in a > way that was semantically different to XFS (for no reason that I > could understand) and nobody wanted two different sets of semantics > for the "same" feature. The most common use of project quotas is to > implement sub-tree quotas, which is probably of more interest to > btrfs folks as it is an exact match for per-subvolume quotas. > > So, yes, I do see it as something generically useful - it's a > feature that a lot of people use XFS specifically for.... I'd agree. There was the tree quota project for ext4, and I've also heard this is available in other filesystems. Cheers, Andreas

April 27, 2012

Re: user32/tests: Update DlgDirList tests

by Bruno Jesus

On Sat, Apr 14, 2012 at 21:57, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Based on original patch from Christian Lupien from bug 8226. > > Tests required to later fix http://bugs.winehq.org/show_bug.cgi?id=8226 Is there anything else I could provide in helping to get this patch accepted? http://source.winehq.org/patches/data/85434 Regards, Bruno

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by J. Bruce Fields

On Fri, Apr 27, 2012 at 11:13:06PM +1000, Dave Chinner wrote: > Right now it is, but there's ben patches in the past to introduce > project quotas to ext4. That didn't go far because it was done in a > way that was semantically different to XFS (for no reason that I > could understand) and nobody wanted two different sets of semantics > for the "same" feature. The most common use of project quotas is to > implement sub-tree quotas, (Though it's also useful as a way to do safe subtree NFS exports). --b. > which is probably of more interest to > btrfs folks as it is an exact match for per-subvolume quotas. > > So, yes, I do see it as something generically useful - it's a > feature that a lot of people use XFS specifically for.... > > Cheers, > > Dave. > -- > Dave Chinner > david(a)fromorbit.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Fri, Apr 27, 2012 at 10:39:05AM +0100, David Howells wrote: > Dave Chinner <david(a)fromorbit.com> wrote: > > > If we are adding per-inode flags, then what do we do with filesystem specific > > flags? e.g. XFS has quite a number of per-inode flags that don't align with > > any other filesystem (e.g. filestream allocator, real time file, behaviour > > inheritence flags, etc), but may be useful to retrieve in such a call. We > > currently have an ioctl to get that information from each inode. Have you > > thought about how to handle such flags? > > I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly > which flags you're talking about. The question, though, is what will actually > make use of these flags? Will it just be XFS tools or are they something that > a GUI might make use of? Have a look at fs/xfs/xfs_dinode.h. There's a bunch of flags defined at the bottom of the file. Stuff like the "nodefrag", "nodump", and "prealloc" bits seem fairly generic - they are for indicating that files are to be avoided for defrag or backup purposes, the prealloc bit indicates that fallocate has been used to reserve space on the inode (finding files that space can be punched out of safely), and so on. Currently these things are queried and manipulated by ioctls (XFS_IOC_FSX[GS]ETATTR) along with extent size hints, project quotas, etc. but I think there's some wider use for many of the flags, which is why I was asking is there's any thought to this sort of flag being exposed by the VFS. Historically the flags exposed by the VFS are those used by extN - I see little reason why we should favour one filesystem's flags over any others in an extended stat interface if they are generically useful.... > Either you can add some of them to the ioc flags (which may be impractical, I > grant you) or we'd have to add an arbitrary fs-type specific field and specify > the host fs (the provision of which might not be a bad idea in and of itself) > to tell userspace how to interpret them. Well, that's the complexity, isn't it. I have no good answer to that... > > Along the same lines, filesytsems can have different allocation constraints > > to IO the filesystem block size - ext4 with it's bigalloc hack, XFS with it's > > per-inode extent size hints and the realtime device, etc. Then there's > > optimal IO characteristics (e.g. geometery hints like stripe unit/stripe > > width for the allocation policy of that given file) that applications could > > use if they were present rather than having to expose them through ioctls > > that nobody even knows about... > > Yeah... Not representable by one number. You'd have to unset a flag to say > you were providing this information. > > However, providing a whole bunch of hints about I/O characteristics is probably > beyond this syscall - especially if it isn't constant over the length of a > file. That's specialist knowledge that most applications don't need to know. > Having a generic way to retrieve it, though, may be a good idea. We're continually talking about applications giving us usage hints on what IO they are going to do so the storage can optimise the IO. IO is still a GIGO problem, though, and the idea of geometry hints is to enable us to tell the application to do well formed IO. i.e. less garbage. XFS has ioctls to expose filesystem geometry, optimal IO sizes, the alignment limits for direct IO, etc, and they are very useful to applications that care about high performance IO. A lot of this can be distilled down to a simple set of geometries, and generally speaking they don't change mid way through a file.... > OTOH, there's plenty of uncommitted space, so if we can condense the hints down > to something small, we could perhaps add it later - but from your paragraph > above, it doesn't sound like it'll be small. Allocation block size, minimum sane IO size (to avoid page cache RMW cycles or DIO zeroing), minimum prefered IO size (e.g. stripe unit), optimal IO size for bandwidth (e.g. stripe width). I don't think there's much more than that which will be really usable by applications. > > Perhaps also exposing the project ID for quota purposes, like we do UID and > > GID. That way we wouldn't need a filesystem specific ioctl to read it.... > > Is this an XFS only thing? If so, can it be generalised? Right now it is, but there's ben patches in the past to introduce project quotas to ext4. That didn't go far because it was done in a way that was semantically different to XFS (for no reason that I could understand) and nobody wanted two different sets of semantics for the "same" feature. The most common use of project quotas is to implement sub-tree quotas, which is probably of more interest to btrfs folks as it is an exact match for per-subvolume quotas. So, yes, I do see it as something generically useful - it's a feature that a lot of people use XFS specifically for.... Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 27, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Stefan Dösinger

Am 26.04.2012 22:22 schrieb "Józef Kucia" <joseph.kucia(a)gmail.com>: > MSDN says that dwPitchOrLinearSize is DWORD in the DDS_HEADER. Also, > the same definition is used in a D3D sample. On the other hand, we can > define it as LONG to be safe. Nah, no need in that case. But I recommend to write tests for invalid pitches

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Dave Chinner <david(a)fromorbit.com> wrote: > If we are adding per-inode flags, then what do we do with filesystem specific > flags? e.g. XFS has quite a number of per-inode flags that don't align with > any other filesystem (e.g. filestream allocator, real time file, behaviour > inheritence flags, etc), but may be useful to retrieve in such a call. We > currently have an ioctl to get that information from each inode. Have you > thought about how to handle such flags? I haven't looked at XFS with regard to xstat as yet, so I'm not sure exactly which flags you're talking about. The question, though, is what will actually make use of these flags? Will it just be XFS tools or are they something that a GUI might make use of? Either you can add some of them to the ioc flags (which may be impractical, I grant you) or we'd have to add an arbitrary fs-type specific field and specify the host fs (the provision of which might not be a bad idea in and of itself) to tell userspace how to interpret them. > Along the same lines, filesytsems can have different allocation constraints > to IO the filesystem block size - ext4 with it's bigalloc hack, XFS with it's > per-inode extent size hints and the realtime device, etc. Then there's > optimal IO characteristics (e.g. geometery hints like stripe unit/stripe > width for the allocation policy of that given file) that applications could > use if they were present rather than having to expose them through ioctls > that nobody even knows about... Yeah... Not representable by one number. You'd have to unset a flag to say you were providing this information. However, providing a whole bunch of hints about I/O characteristics is probably beyond this syscall - especially if it isn't constant over the length of a file. That's specialist knowledge that most applications don't need to know. Having a generic way to retrieve it, though, may be a good idea. OTOH, there's plenty of uncommitted space, so if we can condense the hints down to something small, we could perhaps add it later - but from your paragraph above, it doesn't sound like it'll be small. > Perhaps also exposing the project ID for quota purposes, like we do UID and > GID. That way we wouldn't need a filesystem specific ioctl to read it.... Is this an XFS only thing? If so, can it be generalised? David

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Andreas Dilger <adilger(a)dilger.ca> wrote: > > However, since there is a remote file ID, we could add an > > XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr holding this. > > It is a bit strange that the kernel would return a flag that was not > requested, but not fatal. On the other hand, if it costs the kernel nothing to generate this indicator... For network filesystems, for instance, you might know that there is some other file ID because of the way the fs is specified. I was thinking that many of the fields will be given values, even if you don't ask for them, because the values (or approximations thereof) are present in memory already. David

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Andreas Dilger

On 2012-04-26, at 7:06 PM, Dave Chinner wrote: > On Thu, Apr 19, 2012 at 03:05:58PM +0100, David Howells wrote: >> >> Implement a pair of new system calls to provide extended and further extensible stat functions. >> >> The second of the associated patches is the main patch that provides these new system calls: >> >> ssize_t ret = xstat(int dfd, >> const char *filename, >> unsigned atflag, >> unsigned mask, >> struct xstat *buffer); >> >> ssize_t ret = fxstat(int fd, >> unsigned atflag, >> unsigned mask, >> struct xstat *buffer); >> >> which are more fully documented in the first patch's description. >> >> These new stat functions provide a number of useful features, in summary: >> >> (1) More information: creation time, inode generation number, data >> version number, flags/attributes. A subset of these is available >> through a number of filesystems (CIFS, NFS, AFS, Ext4 and BTRFS). > > If we are adding per-inode flags, then what do we do with filesystem > specific flags? e.g. XFS has quite a number of per-inode flags that > don't align with any other filesystem (e.g. filestream allocator, > real time file, behaviour inheritence flags, etc), but may be useful > to retrieve in such a call. We currently have an ioctl to get that > information from each inode. Have you thought about how to handle > such flags? I'm sympathetic to your cause, but I don't want this to degrade into the same morass that it did last time when every attribute under the sun was added to the call. The intent is to replace the stat() call with something that can avoid overhead on filesystems for which some attributes are expensive, and that applications may not need. Some common attributes were added that are used by multiple filesystems. If it is too filesystem-specific, and there is little possibility that these attributes will be usable on other filesystems, then it should remain a filesystem specific ioctl() call. If you can make a case that these attributes have value on a few other filesystems, and applications are reasonably likely to be able to use them, and their addition does not make the API overly complex, then suggest away. > Along the same lines, filesytsems can have different allocation > constraints to IO the filesystem block size - ext4 with it's > bigalloc hack, XFS with it's per-inode extent size hints and the > realtime device, etc. Then there's optimal IO characteristics > (e.g. geometery hints like stripe unit/stripe width for the > allocation policy of that given file) that applications could use > if they were present rather than having to expose them through > ioctls that nobody even knows about... There is already "optimal IO size" that the application can use, how do the geometry hints differ? Userspace is able to handle st_blksize of several MB in size without problems, and any sane application will do the IO sized + aligned on multiples of this. > Perhaps also exposing the project ID for quota purposes, like we do > UID and GID. That way we wouldn't need a filesystem specific ioctl > to read it.... This seems reasonable and generic and simple. This is similar to directory quotas in other filesystems. Cheers, Andreas

April 27, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by Andreas Dilger

On 2012-04-26, at 6:51 PM, Dave Chinner wrote: > On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote: >> I wonder if there's a way to make this explicit - or is it something that if the bit isn't set, you can't use the value in st_blksize. >> I wonder if this value always has to be non-zero to make sure existing >> stat() doesn't explode. > > More likely it probably needs to be non-zero to prevent applications > doing division by block size from exploding... ;) Right, and any application which knows it needs the blocksize should also be requesting it when using the statxat() (or whatever) syscall. Cheers, Andreas

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Dave Chinner

On Thu, Apr 19, 2012 at 03:05:58PM +0100, David Howells wrote: > > Implement a pair of new system calls to provide extended and further extensible > stat functions. > > The second of the associated patches is the main patch that provides these new > system calls: > > ssize_t ret = xstat(int dfd, > const char *filename, > unsigned atflag, > unsigned mask, > struct xstat *buffer); > > ssize_t ret = fxstat(int fd, > unsigned atflag, > unsigned mask, > struct xstat *buffer); > > which are more fully documented in the first patch's description. > > These new stat functions provide a number of useful features, in summary: > > (1) More information: creation time, inode generation number, data version > number, flags/attributes. A subset of these is available through a number > of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). If we are adding per-inode flags, then what do we do with filesystem specific flags? e.g. XFS has quite a number of per-inode flags that don't align with any other filesystem (e.g. filestream allocator, real time file, behaviour inheritence flags, etc), but may be useful to retrieve in such a call. We currently have an ioctl to get that information from each inode. Have you thought about how to handle such flags? Along the same lines, filesytsems can have different allocation constraints to IO the filesystem block size - ext4 with it's bigalloc hack, XFS with it's per-inode extent size hints and the realtime device, etc. Then there's optimal IO characteristics (e.g. geometery hints like stripe unit/stripe width for the allocation policy of that given file) that applications could use if they were present rather than having to expose them through ioctls that nobody even knows about... Perhaps also exposing the project ID for quota purposes, like we do UID and GID. That way we wouldn't need a filesystem specific ioctl to read it.... Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 27, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by Dave Chinner

On Thu, Apr 26, 2012 at 02:32:36PM +0100, David Howells wrote: > Andreas Dilger <adilger(a)dilger.ca> wrote: > > st_blksize may be variable for a distributed filesystem, It can be variable for local filesystems, too. XFS will vary the block size based on the configuration of the inode. e.g. if there is an extent allocation size hint on the inode, or it's on the realtime device, and so on. There is no guarantee that from file to file that it is constant. > I wonder if there's a way to make this explicit - or is it something that if > the bit isn't set, you can't use the value in st_blksize. > I wonder if this > value always has to be non-zero to make sure existing stat() doesn't explode. More likely it probably needs to be non-zero to prevent applications doing division by block size from exploding... ;) Cheers, Dave. -- Dave Chinner david(a)fromorbit.com

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Myklebust, Trond

On Thu, 2012-04-26 at 15:05 -0700, Roland McGrath wrote: > > What if the xstat() and struct xstat eventually becomes what userspace > > uses as stat() (as a wrapper) and struct stat (if such a thing is > > possible with glibc versioning)? > > It's certainly possible with symbol versioning, though it seems much more > likely that we'd stick with the existing struct stat and stat* interfaces > and only have the implementation using statx underneath (e.g. for new > machines or kernel ABIs where the kernel stops providing any calls except > for statxat), at least for the foreseeable future. > > > Do older programs that think they're using stat() and don't know about > > the extra fields available expect to see a useful value in st_ino? > > POSIX requires that st_ino have a useful value for the standard *stat calls. Yes, but we're talking about non-POSIX filesystems here. If the filesystem doesn't have a useful value for st_ino, then the usual way of dealing with those POSIX requirements is to fake up values. The question then becomes whether or not we care if it is the kernel or userland that fakes up those values. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust(a)netapp.com www.netapp.com

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Myklebust, Trond

On Thu, 2012-04-26 at 22:57 +0100, David Howells wrote: > Myklebust, Trond <Trond.Myklebust(a)netapp.com> wrote: > > > You are still not explaining why they need to know the values at all? If > > the values are bogus, then don't return them, and don't set the flag > > that says they are being returned. > th > What if the xstat() and struct xstat eventually becomes what userspace uses as > stat() (as a wrapper) and struct stat (if such a thing is possible with glibc > versioning)? Do older programs that think they're using stat() and don't know > about the extra fields available expect to see a useful value in st_ino? Does it really matter whether it is the kernel or userland that is responsible for faking up inode numbers? If userland wants to use xstat() in order to fake up a stat() call, then it gets to take responsibility for the results. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust(a)netapp.com www.netapp.com

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Andreas Dilger

On 2012-04-26, at 10:52, David Howells <dhowells(a)redhat.com> wrote: > Steve French <smfrench(a)gmail.com> wrote: >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent unique >> identifier, but in the case of CIFS some old servers don't support the calls >> which return inode numbers (or don't return them for all file system types, >> Windows FAT?) so in these cases cifs has to create inode numbers on the fly >> on the client. inode numbers created on the client are not "stable" they can >> change on unmount/remount (which can cause problems for backup applications). > > In the volatile case you'd probably want to unset XSTAT_INO in st_mask as the > inode number is a local fabrication. I'd agree. Why fake up an inode number if the application doesn't care? Most apps don't actually use the inode. The only uses I know for the inode number in userspace are backup, CIFS/NFS servers, and "ls -li" . > However, since there is a remote file ID, > we could add an XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr > holding this. It is a bit strange that the kernel would return a flag that was not requested, but not fatal. > On CIFS this could be the servername + pathname, on NFS this > could be the server address + FH on AFS the cell+volID+FID+uniquifier for > example. That's independent of xstat, however, and wouldn't be returned as > it's a blob that could be quite large. > > I presume in some cases, there is not a unique file ID that persists across > rename. > >> Similarly NFSv4 does not require that servers always return stable inode >> numbers (that will never change) and introduced a concept of "volatile file >> handle." > > Can I presume the inode number cannot be considered stable if the NFS4 FH is > non-volatile? Furthermore, can I presume NFS2/3 inode numbers are supposed to > be stable? > >> Basically the question is whether it is worth reporting a flag on the call >> which returns the inode number to indicate that the inode number is "stable" >> (would not change on reboot or reconnection) or "volatile." Since the >> majority of NFS and SMB2 servers can return stable inode numbers, I don't >> feel strongly about the need for an indicator of "stable" vs. "volatile" but >> I mention it because backup and migration applications mention this (if inode >> numbers are volatile, they may have to check for hardlinks differently for >> example) > > It may be that unsetting XSTAT_INO if you've fabricated the inode number > locally is sufficient. > >>>>> Handle remote filesystems being offline and indicate this with >>>>> XSTAT_INFO_OFFLINE. >>>> >>>> You already have support for an indicator for offline files (HSM), > > Which indicator is this? Or do you mean XSTAT_INFO_OFFLINE? > >>>> would XSTAT_INFO_OFFLINE be intended for the case >>>> where the network session to the server is disconnected >>>> (and in which you case the application does not want to reconnect)? >>> >>> Hmmm... Interesting question. Both NTFS and CIFS have an offline >>> attribute (which is where I originally got this from) - but should I have a >>> separate indicator to indicate the client can't access a server over a >>> network (ie. we've gone to disconnected operation on this file)? >>> E.g. should there be a XSTAT_INFO_DISCONNECTED too? >> >> my reaction is no, since it adds complexity. If you do a stat on a >> disconnected volume (where the network is temporarily down) reconnection will >> be attempted. If reconnection fails then the xstat will either fail or be >> retried forever depending on the value of "hard" vs. "soft" mount flag. > > I was thinking of how to handle disconnected operation, where you can't just > sit there and churn waiting for the server to come back or give an error. On > the other hand, as long as there's some spare space in the struct, we can deal > with that later when we actually start to implement D/O. > > David > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

April 27, 2012

Re: [PATCH 0/6] Extended file stat system call

by Nix

On 26 Apr 2012, Roland McGrath verbalised: >> fileinfoat() perhaps? I think stat*at() is better, though, as people are >> used to the stat function family. > > Names like that were all I had thought of when I said I hadn't thought of > any good ones. ;-) Quite. It's a garden-path function name. "What's a foat and why would I want to put a file in one?" -- NULL && (void)

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

> What if the xstat() and struct xstat eventually becomes what userspace > uses as stat() (as a wrapper) and struct stat (if such a thing is > possible with glibc versioning)? It's certainly possible with symbol versioning, though it seems much more likely that we'd stick with the existing struct stat and stat* interfaces and only have the implementation using statx underneath (e.g. for new machines or kernel ABIs where the kernel stops providing any calls except for statxat), at least for the foreseeable future. > Do older programs that think they're using stat() and don't know about > the extra fields available expect to see a useful value in st_ino? POSIX requires that st_ino have a useful value for the standard *stat calls. Thanks, Roland

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

> fileinfoat() perhaps? I think stat*at() is better, though, as people are > used to the stat function family. Names like that were all I had thought of when I said I hadn't thought of any good ones. ;-)

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Myklebust, Trond <Trond.Myklebust(a)netapp.com> wrote: > You are still not explaining why they need to know the values at all? If > the values are bogus, then don't return them, and don't set the flag > that says they are being returned. What if the xstat() and struct xstat eventually becomes what userspace uses as stat() (as a wrapper) and struct stat (if such a thing is possible with glibc versioning)? Do older programs that think they're using stat() and don't know about the extra fields available expect to see a useful value in st_ino? David

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Roland McGrath <roland(a)hack.frob.com> wrote: > > I've no particular attachment to the name 'xstat'. If you'd prefer > > 'statx' I could go for that. > > I prefer something other than xstat and statx(at) seems acceptable enough. > What I'd really prefer is a name that is less meaninglessly arcane, > but I haven't thought of any good ones. fileinfoat() perhaps? I think stat*at() is better, though, as people are used to the stat function family. David

April 26, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Józef Kucia

On Thu, Apr 26, 2012 at 9:50 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Donnerstag, 26. April 2012, 11:47:51 schrieb Józef Kucia: >> + DWORD pitch_or_linear_size; > Are you aware that lPitch is a (signed) LONG in the original DDSURFACEDESC > structure? Honestly I have no idea why, and I have never seen an app that > passes a negative pitch, but it might lead to obscure bugs if it is not > checked. > > > MSDN says that dwPitchOrLinearSize is DWORD in the DDS_HEADER. Also, the same definition is used in a D3D sample. On the other hand, we can define it as LONG to be safe.

April 26, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Stefan Dösinger

Am Donnerstag, 26. April 2012, 11:47:51 schrieb Józef Kucia: > + DWORD pitch_or_linear_size; Are you aware that lPitch is a (signed) LONG in the original DDSURFACEDESC structure? Honestly I have no idea why, and I have never seen an app that passes a negative pitch, but it might lead to obscure bugs if it is not checked.

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

> I've no particular attachment to the name 'xstat'. If you'd prefer 'statx' I > could go for that. I prefer something other than xstat and statx(at) seems acceptable enough. What I'd really prefer is a name that is less meaninglessly arcane, but I haven't thought of any good ones. Thanks, Roland

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

> Interesting. I wasn't intending to provide both statx() and statxat() > variants, just the latter, in which case I'd've though that -at suffix is > redundant. It's certainly fine to provide only *at flavors for any new syscall, IMHO. The * case is always just a simple degenerate case of *at, and libc can trivially provide the simpler user API as well using the *at syscall. But please keep the uniformity that everything taking a descriptor and AT_* flags is named *at. Thanks, Roland

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

> Roland McGrath <roland(a)hack.frob.com> wrote: > > > statx seems like a better family of names. I also think it's worthwhile to > > see if the interface can be made to more closely match the AIX precedent. > > I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very > closely, at least from a syscall interface point of view. OK. It was just worth a look. Thanks, Roland

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Thu, Apr 26, 2012 at 12:09 PM, Steve French <smfrench(a)gmail.com> wrote: > On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond > <Trond.Myklebust(a)netapp.com> wrote: >> On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote: >>> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond >>> <Trond.Myklebust(a)netapp.com> wrote: >>> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote: >>> >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond >>> >> <Trond.Myklebust(a)netapp.com> wrote: >>> >> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: >>> >> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: >>> >> >> > Steve French <smfrench(a)gmail.com> wrote: >>> >> >> > >>> >> >> >> Would it be better to make the stable vs volatile inode number an attribute >>> >> >> >> of the volume or something returned by the proposed xstat? >>> >> >> > >>> >> >> > I'm not sure what you mean by a stable vs a volatile inode number. >>> >> >> >>> >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent >>> >> >> unique identifier, but in the case of CIFS some old servers don't support the >>> >> >> calls which return inode numbers (or don't return them for all file system >>> >> >> types, Windows FAT?) so in these cases cifs has to create inode >>> >> >> numbers on the fly >>> >> >> on the client. inode numbers created on the client are not "stable" they >>> >> >> can change on unmount/remount (which can cause problems for backup >>> >> >> applications). >>> >> >> >>> >> >> Similarly NFSv4 does not require that servers always return stable inode numbers >>> >> >> (that will never change) and introduced a concept of "volatile file handle." >>> >> >> We have run into this in two cases (there are probably more) - >>> >> >> Specialized NFS servers >>> >> >> for HPC which deal with lots of transient inodes, and second those for servers >>> >> >> which base there inode number on path (Windows NFS?). See >>> >> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html >>> >> >> or the NFSv4 RFC. >>> >> >> >>> >> >> Basically the question is whether it is worth reporting a flag on the >>> >> >> call which returns >>> >> >> the inode number to indicate that the inode number is "stable" (would not change >>> >> >> on reboot or reconnection) or "volatile." Since the majority of NFS >>> >> >> and SMB2 servers >>> >> >> can return stable inode numbers, I don't feel strongly about the need >>> >> >> for an indicator >>> >> >> of "stable" vs. "volatile" but I mention it because backup and >>> >> >> migration applications >>> >> >> mention this (if inode numbers are volatile, they may have to check >>> >> >> for hardlinks differently >>> >> >> for example) >>> >> > >>> >> > I don't understand. If the filesystem doesn't support real inode >>> >> > numbers, then why report them at all? What use would an application have >>> >> > for an inode number that can't be used to identify hard linked files? >>> >> >>> >> Well ... you have to have an inode number on the Linux client side even if >>> >> the server doesn't report them (or has a bug and reports duplicates). >>> >> If you can't tell hardlinked files apart fix the server (but in the >>> >> cases where the file systems has this problem the server doesn't usually >>> >> support hardlinks either). >>> >> >>> >> If the server's file system internal structures don't support real inode >>> >> numbers (such as FAT or a ramdisk) then it either has to make them >>> >> up based on something like path name or some other attribute of the >>> >> file on disk. >>> >> >>> >> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009 >>> >> query file info is used to query_file_internal_info (the inode number) but >>> >> what if the server can not report inode numbers (due to a bug) in >>> >> all cases. >>> > >>> > Right, but none of this explains why we need to report these bogus inode >>> > numbers to the application in the xstat() reply. >>> >>> the question is whether the application (backup) would need to know >>> that the inode numbers are bogus and from my conversations with >>> guys writing backup software it seems that such data is useful to them. >> >> You are still not explaining why they need to know the values at all? If >> the values are bogus, then don't return them, and don't set the flag >> that says they are being returned. > > I don't know, but assumed it was because it was an easy way > to index them since the inode numbers even if they "change" > on remount, are still unique. if the call allows the inode number not to be returned, that is probably ok (they can always use the posix stat to get the client generated one) -- Thanks, Steve

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond <Trond.Myklebust(a)netapp.com> wrote: > On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote: >> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond >> <Trond.Myklebust(a)netapp.com> wrote: >> > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote: >> >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond >> >> <Trond.Myklebust(a)netapp.com> wrote: >> >> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: >> >> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: >> >> >> > Steve French <smfrench(a)gmail.com> wrote: >> >> >> > >> >> >> >> Would it be better to make the stable vs volatile inode number an attribute >> >> >> >> of the volume or something returned by the proposed xstat? >> >> >> > >> >> >> > I'm not sure what you mean by a stable vs a volatile inode number. >> >> >> >> >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent >> >> >> unique identifier, but in the case of CIFS some old servers don't support the >> >> >> calls which return inode numbers (or don't return them for all file system >> >> >> types, Windows FAT?) so in these cases cifs has to create inode >> >> >> numbers on the fly >> >> >> on the client. inode numbers created on the client are not "stable" they >> >> >> can change on unmount/remount (which can cause problems for backup >> >> >> applications). >> >> >> >> >> >> Similarly NFSv4 does not require that servers always return stable inode numbers >> >> >> (that will never change) and introduced a concept of "volatile file handle." >> >> >> We have run into this in two cases (there are probably more) - >> >> >> Specialized NFS servers >> >> >> for HPC which deal with lots of transient inodes, and second those for servers >> >> >> which base there inode number on path (Windows NFS?). See >> >> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html >> >> >> or the NFSv4 RFC. >> >> >> >> >> >> Basically the question is whether it is worth reporting a flag on the >> >> >> call which returns >> >> >> the inode number to indicate that the inode number is "stable" (would not change >> >> >> on reboot or reconnection) or "volatile." Since the majority of NFS >> >> >> and SMB2 servers >> >> >> can return stable inode numbers, I don't feel strongly about the need >> >> >> for an indicator >> >> >> of "stable" vs. "volatile" but I mention it because backup and >> >> >> migration applications >> >> >> mention this (if inode numbers are volatile, they may have to check >> >> >> for hardlinks differently >> >> >> for example) >> >> > >> >> > I don't understand. If the filesystem doesn't support real inode >> >> > numbers, then why report them at all? What use would an application have >> >> > for an inode number that can't be used to identify hard linked files? >> >> >> >> Well ... you have to have an inode number on the Linux client side even if >> >> the server doesn't report them (or has a bug and reports duplicates). >> >> If you can't tell hardlinked files apart fix the server (but in the >> >> cases where the file systems has this problem the server doesn't usually >> >> support hardlinks either). >> >> >> >> If the server's file system internal structures don't support real inode >> >> numbers (such as FAT or a ramdisk) then it either has to make them >> >> up based on something like path name or some other attribute of the >> >> file on disk. >> >> >> >> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009 >> >> query file info is used to query_file_internal_info (the inode number) but >> >> what if the server can not report inode numbers (due to a bug) in >> >> all cases. >> > >> > Right, but none of this explains why we need to report these bogus inode >> > numbers to the application in the xstat() reply. >> >> the question is whether the application (backup) would need to know >> that the inode numbers are bogus and from my conversations with >> guys writing backup software it seems that such data is useful to them. > > You are still not explaining why they need to know the values at all? If > the values are bogus, then don't return them, and don't set the flag > that says they are being returned. I don't know, but assumed it was because it was an easy way to index them since the inode numbers even if they "change" on remount, are still unique. -- Thanks, Steve

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Myklebust, Trond

On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote: > On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond > <Trond.Myklebust(a)netapp.com> wrote: > > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote: > >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond > >> <Trond.Myklebust(a)netapp.com> wrote: > >> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: > >> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: > >> >> > Steve French <smfrench(a)gmail.com> wrote: > >> >> > > >> >> >> Would it be better to make the stable vs volatile inode number an attribute > >> >> >> of the volume or something returned by the proposed xstat? > >> >> > > >> >> > I'm not sure what you mean by a stable vs a volatile inode number. > >> >> > >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent > >> >> unique identifier, but in the case of CIFS some old servers don't support the > >> >> calls which return inode numbers (or don't return them for all file system > >> >> types, Windows FAT?) so in these cases cifs has to create inode > >> >> numbers on the fly > >> >> on the client. inode numbers created on the client are not "stable" they > >> >> can change on unmount/remount (which can cause problems for backup > >> >> applications). > >> >> > >> >> Similarly NFSv4 does not require that servers always return stable inode numbers > >> >> (that will never change) and introduced a concept of "volatile file handle." > >> >> We have run into this in two cases (there are probably more) - > >> >> Specialized NFS servers > >> >> for HPC which deal with lots of transient inodes, and second those for servers > >> >> which base there inode number on path (Windows NFS?). See > >> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html > >> >> or the NFSv4 RFC. > >> >> > >> >> Basically the question is whether it is worth reporting a flag on the > >> >> call which returns > >> >> the inode number to indicate that the inode number is "stable" (would not change > >> >> on reboot or reconnection) or "volatile." Since the majority of NFS > >> >> and SMB2 servers > >> >> can return stable inode numbers, I don't feel strongly about the need > >> >> for an indicator > >> >> of "stable" vs. "volatile" but I mention it because backup and > >> >> migration applications > >> >> mention this (if inode numbers are volatile, they may have to check > >> >> for hardlinks differently > >> >> for example) > >> > > >> > I don't understand. If the filesystem doesn't support real inode > >> > numbers, then why report them at all? What use would an application have > >> > for an inode number that can't be used to identify hard linked files? > >> > >> Well ... you have to have an inode number on the Linux client side even if > >> the server doesn't report them (or has a bug and reports duplicates). > >> If you can't tell hardlinked files apart fix the server (but in the > >> cases where the file systems has this problem the server doesn't usually > >> support hardlinks either). > >> > >> If the server's file system internal structures don't support real inode > >> numbers (such as FAT or a ramdisk) then it either has to make them > >> up based on something like path name or some other attribute of the > >> file on disk. > >> > >> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009 > >> query file info is used to query_file_internal_info (the inode number) but > >> what if the server can not report inode numbers (due to a bug) in > >> all cases. > > > > Right, but none of this explains why we need to report these bogus inode > > numbers to the application in the xstat() reply. > > the question is whether the application (backup) would need to know > that the inode numbers are bogus and from my conversations with > guys writing backup software it seems that such data is useful to them. You are still not explaining why they need to know the values at all? If the values are bogus, then don't return them, and don't set the flag that says they are being returned. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust(a)netapp.com www.netapp.com

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by Steve French

On Thu, Apr 26, 2012 at 9:28 AM, J. Bruce Fields <bfields(a)fieldses.org> wrote: > On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote: >> Steve French <smfrench(a)gmail.com> wrote: >> >> > I also would prefer that we simply treat the time granularity as part >> > of the superblock (mounted volume) ie returned on fstat rather than on >> > every stat of the filesystem. For cifs mounts we could conceivably >> > have different time granularity (1 or 2 second) on mounts to old >> > servers rather than 100 nanoseconds. >> >> The question is whether you want to have to do a statfs in addition to a stat? >> I suppose you can potentially cache the statfs based on device number. >> >> That said, there are cases where caching filesystem-level info based on i_dev >> doesn't work. OpenAFS springs to mind as that only has one superblock and >> thus one set of device numbers, but keeps all the inodes for all the different >> volumes it may have mounted there. >> >> I don't know whether this would be a problem for CIFS too - say on a windows >> server you fabricate P:, for example, by joining together several filesystems >> (with junctions?). How does this appear on a Linux client when it steps from >> one filesystem to another within a mounted share? > > In the NFS case we do try to preserve filesystem boundaries as well as > we can--the protocol has an fsid field and the client creates a new > mount each time it sees it change. And the protocol defines time_delta > as a per-filesystem attribute (though, somewhat hilariously, there's > also a per-filesystem "homogeneous" attribute that a server can clear to > indicate the per-filesystem attributes might actually vary within the > filesystem.) Thank you for reminding me, I need to look at this case more ... although cifs creates implicit submounts (as we traverse DFS referrals) there are probably cases where we need to do the same thing as NFS and look at the fsid so we don't run into a Windows server exporting something with a "junction" (e.g. directory redirection to a DVD drive for example) and thus cross file system volume boundaries. -- Thanks, Steve

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond <Trond.Myklebust(a)netapp.com> wrote: > On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote: >> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond >> <Trond.Myklebust(a)netapp.com> wrote: >> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: >> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: >> >> > Steve French <smfrench(a)gmail.com> wrote: >> >> > >> >> >> Would it be better to make the stable vs volatile inode number an attribute >> >> >> of the volume or something returned by the proposed xstat? >> >> > >> >> > I'm not sure what you mean by a stable vs a volatile inode number. >> >> >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent >> >> unique identifier, but in the case of CIFS some old servers don't support the >> >> calls which return inode numbers (or don't return them for all file system >> >> types, Windows FAT?) so in these cases cifs has to create inode >> >> numbers on the fly >> >> on the client. inode numbers created on the client are not "stable" they >> >> can change on unmount/remount (which can cause problems for backup >> >> applications). >> >> >> >> Similarly NFSv4 does not require that servers always return stable inode numbers >> >> (that will never change) and introduced a concept of "volatile file handle." >> >> We have run into this in two cases (there are probably more) - >> >> Specialized NFS servers >> >> for HPC which deal with lots of transient inodes, and second those for servers >> >> which base there inode number on path (Windows NFS?). See >> >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html >> >> or the NFSv4 RFC. >> >> >> >> Basically the question is whether it is worth reporting a flag on the >> >> call which returns >> >> the inode number to indicate that the inode number is "stable" (would not change >> >> on reboot or reconnection) or "volatile." Since the majority of NFS >> >> and SMB2 servers >> >> can return stable inode numbers, I don't feel strongly about the need >> >> for an indicator >> >> of "stable" vs. "volatile" but I mention it because backup and >> >> migration applications >> >> mention this (if inode numbers are volatile, they may have to check >> >> for hardlinks differently >> >> for example) >> > >> > I don't understand. If the filesystem doesn't support real inode >> > numbers, then why report them at all? What use would an application have >> > for an inode number that can't be used to identify hard linked files? >> >> Well ... you have to have an inode number on the Linux client side even if >> the server doesn't report them (or has a bug and reports duplicates). >> If you can't tell hardlinked files apart fix the server (but in the >> cases where the file systems has this problem the server doesn't usually >> support hardlinks either). >> >> If the server's file system internal structures don't support real inode >> numbers (such as FAT or a ramdisk) then it either has to make them >> up based on something like path name or some other attribute of the >> file on disk. >> >> Servers like NetApp is where this gets interesting - for cifs e.g. level 1009 >> query file info is used to query_file_internal_info (the inode number) but >> what if the server can not report inode numbers (due to a bug) in >> all cases. > > Right, but none of this explains why we need to report these bogus inode > numbers to the application in the xstat() reply. the question is whether the application (backup) would need to know that the inode numbers are bogus and from my conversations with guys writing backup software it seems that such data is useful to them. -- Thanks, Steve

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Myklebust, Trond

On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote: > On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond > <Trond.Myklebust(a)netapp.com> wrote: > > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: > >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: > >> > Steve French <smfrench(a)gmail.com> wrote: > >> > > >> >> Would it be better to make the stable vs volatile inode number an attribute > >> >> of the volume or something returned by the proposed xstat? > >> > > >> > I'm not sure what you mean by a stable vs a volatile inode number. > >> > >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent > >> unique identifier, but in the case of CIFS some old servers don't support the > >> calls which return inode numbers (or don't return them for all file system > >> types, Windows FAT?) so in these cases cifs has to create inode > >> numbers on the fly > >> on the client. inode numbers created on the client are not "stable" they > >> can change on unmount/remount (which can cause problems for backup > >> applications). > >> > >> Similarly NFSv4 does not require that servers always return stable inode numbers > >> (that will never change) and introduced a concept of "volatile file handle." > >> We have run into this in two cases (there are probably more) - > >> Specialized NFS servers > >> for HPC which deal with lots of transient inodes, and second those for servers > >> which base there inode number on path (Windows NFS?). See > >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html > >> or the NFSv4 RFC. > >> > >> Basically the question is whether it is worth reporting a flag on the > >> call which returns > >> the inode number to indicate that the inode number is "stable" (would not change > >> on reboot or reconnection) or "volatile." Since the majority of NFS > >> and SMB2 servers > >> can return stable inode numbers, I don't feel strongly about the need > >> for an indicator > >> of "stable" vs. "volatile" but I mention it because backup and > >> migration applications > >> mention this (if inode numbers are volatile, they may have to check > >> for hardlinks differently > >> for example) > > > > I don't understand. If the filesystem doesn't support real inode > > numbers, then why report them at all? What use would an application have > > for an inode number that can't be used to identify hard linked files? > > Well ... you have to have an inode number on the Linux client side even if > the server doesn't report them (or has a bug and reports duplicates). > If you can't tell hardlinked files apart fix the server (but in the > cases where the file systems has this problem the server doesn't usually > support hardlinks either). > > If the server's file system internal structures don't support real inode > numbers (such as FAT or a ramdisk) then it either has to make them > up based on something like path name or some other attribute of the > file on disk. > > Servers like NetApp is where this gets interesting - for cifs e.g. level 1009 > query file info is used to query_file_internal_info (the inode number) but > what if the server can not report inode numbers (due to a bug) in > all cases. Right, but none of this explains why we need to report these bogus inode numbers to the application in the xstat() reply. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust(a)netapp.com www.netapp.com

April 26, 2012

Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

by Steve French

On Thu, Apr 26, 2012 at 8:47 AM, David Howells <dhowells(a)redhat.com> wrote: > Steve French <smfrench(a)gmail.com> wrote: > >> This patch reminds me of a question on time stamps - how can an >> application query the time granularity ie sb_s_time_gran for a mount >> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1 >> nanosecond for others etc.) > > Ummm... In what context? With the proposed xstat() interface it will be > provided. great (although I thought it would be "stat -f" property). -- Thanks, Steve

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond <Trond.Myklebust(a)netapp.com> wrote: > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: >> > Steve French <smfrench(a)gmail.com> wrote: >> > >> >> Would it be better to make the stable vs volatile inode number an attribute >> >> of the volume or something returned by the proposed xstat? >> > >> > I'm not sure what you mean by a stable vs a volatile inode number. >> >> Both NFS and CIFS (and SMB2) can return inode numbers or equivalent >> unique identifier, but in the case of CIFS some old servers don't support the >> calls which return inode numbers (or don't return them for all file system >> types, Windows FAT?) so in these cases cifs has to create inode >> numbers on the fly >> on the client. inode numbers created on the client are not "stable" they >> can change on unmount/remount (which can cause problems for backup >> applications). >> >> Similarly NFSv4 does not require that servers always return stable inode numbers >> (that will never change) and introduced a concept of "volatile file handle." >> We have run into this in two cases (there are probably more) - >> Specialized NFS servers >> for HPC which deal with lots of transient inodes, and second those for servers >> which base there inode number on path (Windows NFS?). See >> http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html >> or the NFSv4 RFC. >> >> Basically the question is whether it is worth reporting a flag on the >> call which returns >> the inode number to indicate that the inode number is "stable" (would not change >> on reboot or reconnection) or "volatile." Since the majority of NFS >> and SMB2 servers >> can return stable inode numbers, I don't feel strongly about the need >> for an indicator >> of "stable" vs. "volatile" but I mention it because backup and >> migration applications >> mention this (if inode numbers are volatile, they may have to check >> for hardlinks differently >> for example) > > I don't understand. If the filesystem doesn't support real inode > numbers, then why report them at all? What use would an application have > for an inode number that can't be used to identify hard linked files? Well ... you have to have an inode number on the Linux client side even if the server doesn't report them (or has a bug and reports duplicates). If you can't tell hardlinked files apart fix the server (but in the cases where the file systems has this problem the server doesn't usually support hardlinks either). If the server's file system internal structures don't support real inode numbers (such as FAT or a ramdisk) then it either has to make them up based on something like path name or some other attribute of the file on disk. Servers like NetApp is where this gets interesting - for cifs e.g. level 1009 query file info is used to query_file_internal_info (the inode number) but what if the server can not report inode numbers (due to a bug) in all cases. -- Thanks, Steve

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Steve French <smfrench(a)gmail.com> wrote: > >> Would it be better to make the stable vs volatile inode number an attribute > >> of the volume or something returned by the proposed xstat? > > > > I'm not sure what you mean by a stable vs a volatile inode number. > > Both NFS and CIFS (and SMB2) can return inode numbers or equivalent unique > identifier, but in the case of CIFS some old servers don't support the calls > which return inode numbers (or don't return them for all file system types, > Windows FAT?) so in these cases cifs has to create inode numbers on the fly > on the client. inode numbers created on the client are not "stable" they can > change on unmount/remount (which can cause problems for backup applications). In the volatile case you'd probably want to unset XSTAT_INO in st_mask as the inode number is a local fabrication. However, since there is a remote file ID, we could add an XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr holding this. On CIFS this could be the servername + pathname, on NFS this could be the server address + FH on AFS the cell+volID+FID+uniquifier for example. That's independent of xstat, however, and wouldn't be returned as it's a blob that could be quite large. I presume in some cases, there is not a unique file ID that persists across rename. > Similarly NFSv4 does not require that servers always return stable inode > numbers (that will never change) and introduced a concept of "volatile file > handle." Can I presume the inode number cannot be considered stable if the NFS4 FH is non-volatile? Furthermore, can I presume NFS2/3 inode numbers are supposed to be stable? > Basically the question is whether it is worth reporting a flag on the call > which returns the inode number to indicate that the inode number is "stable" > (would not change on reboot or reconnection) or "volatile." Since the > majority of NFS and SMB2 servers can return stable inode numbers, I don't > feel strongly about the need for an indicator of "stable" vs. "volatile" but > I mention it because backup and migration applications mention this (if inode > numbers are volatile, they may have to check for hardlinks differently for > example) It may be that unsetting XSTAT_INO if you've fabricated the inode number locally is sufficient. > >> > Handle remote filesystems being offline and indicate this with > >> > XSTAT_INFO_OFFLINE. > >> > >> You already have support for an indicator for offline files (HSM), Which indicator is this? Or do you mean XSTAT_INFO_OFFLINE? > >> would XSTAT_INFO_OFFLINE be intended for the case > >> where the network session to the server is disconnected > >> (and in which you case the application does not want to reconnect)? > > > > Hmmm... Interesting question. Both NTFS and CIFS have an offline > > attribute (which is where I originally got this from) - but should I have a > > separate indicator to indicate the client can't access a server over a > > network (ie. we've gone to disconnected operation on this file)? > > E.g. should there be a XSTAT_INFO_DISCONNECTED too? > > my reaction is no, since it adds complexity. If you do a stat on a > disconnected volume (where the network is temporarily down) reconnection will > be attempted. If reconnection fails then the xstat will either fail or be > retried forever depending on the value of "hard" vs. "soft" mount flag. I was thinking of how to handle disconnected operation, where you can't just sit there and churn waiting for the server to come back or give an error. On the other hand, as long as there's some spare space in the struct, we can deal with that later when we actually start to implement D/O. David

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Myklebust, Trond

On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: > On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: > > Steve French <smfrench(a)gmail.com> wrote: > > > >> Would it be better to make the stable vs volatile inode number an attribute > >> of the volume or something returned by the proposed xstat? > > > > I'm not sure what you mean by a stable vs a volatile inode number. > > Both NFS and CIFS (and SMB2) can return inode numbers or equivalent > unique identifier, but in the case of CIFS some old servers don't support the > calls which return inode numbers (or don't return them for all file system > types, Windows FAT?) so in these cases cifs has to create inode > numbers on the fly > on the client. inode numbers created on the client are not "stable" they > can change on unmount/remount (which can cause problems for backup > applications). > > Similarly NFSv4 does not require that servers always return stable inode numbers > (that will never change) and introduced a concept of "volatile file handle." > We have run into this in two cases (there are probably more) - > Specialized NFS servers > for HPC which deal with lots of transient inodes, and second those for servers > which base there inode number on path (Windows NFS?). See > http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html > or the NFSv4 RFC. > > Basically the question is whether it is worth reporting a flag on the > call which returns > the inode number to indicate that the inode number is "stable" (would not change > on reboot or reconnection) or "volatile." Since the majority of NFS > and SMB2 servers > can return stable inode numbers, I don't feel strongly about the need > for an indicator > of "stable" vs. "volatile" but I mention it because backup and > migration applications > mention this (if inode numbers are volatile, they may have to check > for hardlinks differently > for example) I don't understand. If the filesystem doesn't support real inode numbers, then why report them at all? What use would an application have for an inode number that can't be used to identify hard linked files? Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust(a)netapp.com www.netapp.com

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: > Steve French <smfrench(a)gmail.com> wrote: > >> Would it be better to make the stable vs volatile inode number an attribute >> of the volume or something returned by the proposed xstat? > > I'm not sure what you mean by a stable vs a volatile inode number. Both NFS and CIFS (and SMB2) can return inode numbers or equivalent unique identifier, but in the case of CIFS some old servers don't support the calls which return inode numbers (or don't return them for all file system types, Windows FAT?) so in these cases cifs has to create inode numbers on the fly on the client. inode numbers created on the client are not "stable" they can change on unmount/remount (which can cause problems for backup applications). Similarly NFSv4 does not require that servers always return stable inode numbers (that will never change) and introduced a concept of "volatile file handle." We have run into this in two cases (there are probably more) - Specialized NFS servers for HPC which deal with lots of transient inodes, and second those for servers which base there inode number on path (Windows NFS?). See http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html or the NFSv4 RFC. Basically the question is whether it is worth reporting a flag on the call which returns the inode number to indicate that the inode number is "stable" (would not change on reboot or reconnection) or "volatile." Since the majority of NFS and SMB2 servers can return stable inode numbers, I don't feel strongly about the need for an indicator of "stable" vs. "volatile" but I mention it because backup and migration applications mention this (if inode numbers are volatile, they may have to check for hardlinks differently for example) >> > Should things like the Windows Archive, Hidden and System bits be handled >> > through IOC flags, perhaps expanded to 64-bits? >> >> Today I export these through an psuedo-xattr in cifs.ko, I am curious how >> NTFS and FAT export these on linux. > > NTFS: Not at all. > > FAT: The hidden bit causes the filename to get a dot prepended (and nothing > else is noted). > >> > Autofs, ntfs, btrfs, ... >> >> Given the overlap in optional attributes between the network >> protocol and local NTFS (and ReFS and to a lesser extent FAT) >> I would expect cifs.ko and the ntfs implementations >> info to map pretty closely. > > Yep. I wasn't going to do more filesystems till we'd finished arguing about > the basic arrangement of things in struct xstat. makes sense >> > Handle remote filesystems being offline and indicate this with >> > XSTAT_INFO_OFFLINE. >> >> You already have support for an indicator for offline files (HSM), > > HSM HSM is the more general case of two tiered data (disk vs. tape) en.wikipedia.org/wiki/Hierarchical_storage_management in the simplest case on "disk" (fast) vs. moved to tape (slow to retrieve) >> would XSTAT_INFO_OFFLINE be intended for the case >> where the network session to the server is disconnected >> (and in which you case the application does not want to reconnect)? > > Hmmm... Interesting question. Both NTFS and CIFS have an offline attribute > (which is where I originally got this from) - but should I have a separate > indicator to indicate the client can't access a server over a network > (ie. we've gone to disconnected operation on this file)? E.g. should there be > a XSTAT_INFO_DISCONNECTED too? my reaction is no, since it adds complexity. If you do a stat on a disconnected volume (where the network is temporarily down) reconnection will be attempted. If reconnection fails then the xstat will either fail or be retried forever depending on the value of "hard" vs. "soft" mount flag. -- Thanks, Steve

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by J. Bruce Fields

On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote: > Steve French <smfrench(a)gmail.com> wrote: > > > I also would prefer that we simply treat the time granularity as part > > of the superblock (mounted volume) ie returned on fstat rather than on > > every stat of the filesystem. For cifs mounts we could conceivably > > have different time granularity (1 or 2 second) on mounts to old > > servers rather than 100 nanoseconds. > > The question is whether you want to have to do a statfs in addition to a stat? > I suppose you can potentially cache the statfs based on device number. > > That said, there are cases where caching filesystem-level info based on i_dev > doesn't work. OpenAFS springs to mind as that only has one superblock and > thus one set of device numbers, but keeps all the inodes for all the different > volumes it may have mounted there. > > I don't know whether this would be a problem for CIFS too - say on a windows > server you fabricate P:, for example, by joining together several filesystems > (with junctions?). How does this appear on a Linux client when it steps from > one filesystem to another within a mounted share? In the NFS case we do try to preserve filesystem boundaries as well as we can--the protocol has an fsid field and the client creates a new mount each time it sees it change. And the protocol defines time_delta as a per-filesystem attribute (though, somewhat hilariously, there's also a per-filesystem "homogeneous" attribute that a server can clear to indicate the per-filesystem attributes might actually vary within the filesystem.) --b.

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Steve French <smfrench(a)gmail.com> wrote: > Would it be better to make the stable vs volatile inode number an attribute > of the volume or something returned by the proposed xstat? I'm not sure what you mean by a stable vs a volatile inode number. > > Should things like the Windows Archive, Hidden and System bits be handled > > through IOC flags, perhaps expanded to 64-bits? > > Today I export these through an psuedo-xattr in cifs.ko, I am curious how > NTFS and FAT export these on linux. NTFS: Not at all. FAT: The hidden bit causes the filename to get a dot prepended (and nothing else is noted). > > Autofs, ntfs, btrfs, ... > > Given the overlap in optional attributes between the network > protocol and local NTFS (and ReFS and to a lesser extent FAT) > I would expect cifs.ko and the ntfs implementations > info to map pretty closely. Yep. I wasn't going to do more filesystems till we'd finished arguing about the basic arrangement of things in struct xstat. > > Handle remote filesystems being offline and indicate this with > > XSTAT_INFO_OFFLINE. > > You already have support for an indicator for offline files (HSM), HSM? > would XSTAT_INFO_OFFLINE be intended for the case > where the network session to the server is disconnected > (and in which you case the application does not want to reconnect)? Hmmm... Interesting question. Both NTFS and CIFS have an offline attribute (which is where I originally got this from) - but should I have a separate indicator to indicate the client can't access a server over a network (ie. we've gone to disconnected operation on this file)? E.g. should there be a XSTAT_INFO_DISCONNECTED too? David

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by J. Bruce Fields

On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote: > J. Bruce Fields <bfields(a)fieldses.org> wrote: > > > > (11) Include granularity fields in the time data to indicate the > > > granularity of each of the times (NFSv4 time_delta) [Steve French]. > > > > It looks like you're including this with *each* time? But surely > > there's no filesystem with different granularity (say) for ctime than > > for mtime. > > I put it in each time struct to use up the hole there. I could, I suppose, > split tv_sec from tv_nsec to get rid of the holes and then put the granularity > separately. That means that someone who wanted both the tv_sec and tv_nsec > would have to fish them out separately, but that's probably okay. > > I could even make the granularity bigger then, to allow for the possibility of > having a granularity >4s, but I don't know of anywhere that requires a gran >2. > > > Also, nfsd will want only one time_delta, not one for each time. > > time_delta? Is that the same as granularity? Right, sorry, that's just the NFS word for the same thing. So my whine here is just that most callers only want to know one number and we're giving them three. Whatever, they can just pick one. It feels a little ugly, but feel free to ignore my nitpicking.... (Though as Steve French asked: could we add this to statfs (or something similar) instead?) > > > Note also we need to document carefully what this means: I think it > > should be the granularity that the filesystem is capable of > > representing, but people are sometimes surprised to find out that the > > actual time source is usually more coarse-grained than that. > > Yeah, but the latter is something you may not be able to determine, and may > indeed change over time (say someone updates the server kernel to one with a > more fine-grained software clock). Also, for a network fs, it may depend on > the client that happened to set that time last. Yep, agreed, the granularity should be what the filesystem can store, we should just make sure that statement makes it into any eventual man pages or other documentation, since it does seem to surprise people. --b.

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Roland McGrath <roland(a)hack.frob.com> wrote: > statx seems like a better family of names. I also think it's worthwhile to > see if the interface can be made to more closely match the AIX precedent. I'm not sure we can make Linux xstat (or whatever) match AIX statxat() very closely, at least from a syscall interface point of view. We really need the AT_* flags mask to be compatible with the other Linux syscalls and the length parameter that I originally had got argued out of existence. I would also like to make it so that there aren't different 32-bit and 64-bit interfaces to the kernel - though that means a burden on glibc/uClibc/etc., I guess. I do also want to be able to pass a mask of what we're actually interested in - but that's not part of the AIX interface. I also like the idea of having a larger buffer with the ability to return extra info (such as security label xattrs), but I was told it was a poor idea, so that got taken out. David

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Paul Eggert <eggert(a)cs.ucla.edu> wrote: > On 04/19/2012 09:32 AM, Roland McGrath wrote: > > I have no comment on the functionality. But "xstat" is probably a poor > > choice of name. > > In AIX 7.1 the (similar) function is called statxat instead of xstat. > The API isn't exactly the same, but it's the same basic idea. > Might be worth looking at, not merely to see whether the API > should be the same, but also to borrow good ideas even if not. > > http://pic.dhe.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.basetechref/do… Interesting. I wasn't intending to provide both statx() and statxat() variants, just the latter, in which case I'd've though that -at suffix is redundant. I note that they split their time fields into separate seconds and ns fields, presumably for better packing. David

April 26, 2012

Re: [PATCH 0/6] Extended file stat system call

by David Howells

Roland McGrath <roland(a)hack.frob.com> wrote: > I have no comment on the functionality. But "xstat" is probably a poor > choice of name. There is precedent for that function name with different > meaning in the userland APIs. (It's a moderately useless meaning inherited > from SVR4, but regardless overloading a name previously used is unwise.) I've no particular attachment to the name 'xstat'. If you'd prefer 'statx' I could go for that. David

April 26, 2012

Re: [PATCH 4/6] xstat: NFS: Return extended attributes

by David Howells

Myklebust, Trond <Trond.Myklebust(a)netapp.com> wrote: > Hmm... As far as I can see you are still doing an nfs_revalidate_inode() > in the non-forced case. That will cause expired attributes to be > retrieved from the server. Revalidation is only done when you force it or explicitly ask for a basic stat or the data version number: - if (need_atime) - err = __nfs_revalidate_inode(NFS_SERVER(inode), inode); - else - err = nfs_revalidate_inode(NFS_SERVER(inode), inode); - if (!err) { - generic_fillattr(inode, stat); - stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); + if (force || stat->request_mask & (XSTAT_BASIC_STATS | XSTAT_VERSION)) { + if (force || need_atime) + err = __nfs_revalidate_inode(NFS_SERVER(inode), inode); + else + err = nfs_revalidate_inode(NFS_SERVER(inode), inode); + if (err) + goto out; Unfortunately, I think I have to revalidate if any of XSTAT_BASIC_STATS are requested to maintain compatibility with stat() so that stat() can be done with xstat(). On the other hand, stat() could be done by userspace with xstat() and AT_FORCE_ATTR_SYNC, I suppose. David

April 26, 2012

Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

by David Howells

Steve French <smfrench(a)gmail.com> wrote: > This patch reminds me of a question on time stamps - how can an > application query the time granularity ie sb_s_time_gran for a mount > (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1 > nanosecond for others etc.) Ummm... In what context? With the proposed xstat() interface it will be provided. David

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by David Howells

Steve French <smfrench(a)gmail.com> wrote: > I also would prefer that we simply treat the time granularity as part > of the superblock (mounted volume) ie returned on fstat rather than on > every stat of the filesystem. For cifs mounts we could conceivably > have different time granularity (1 or 2 second) on mounts to old > servers rather than 100 nanoseconds. The question is whether you want to have to do a statfs in addition to a stat? I suppose you can potentially cache the statfs based on device number. That said, there are cases where caching filesystem-level info based on i_dev doesn't work. OpenAFS springs to mind as that only has one superblock and thus one set of device numbers, but keeps all the inodes for all the different volumes it may have mounted there. I don't know whether this would be a problem for CIFS too - say on a windows server you fabricate P:, for example, by joining together several filesystems (with junctions?). How does this appear on a Linux client when it steps from one filesystem to another within a mounted share? David

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by David Howells

J. Bruce Fields <bfields(a)fieldses.org> wrote: > > (11) Include granularity fields in the time data to indicate the > > granularity of each of the times (NFSv4 time_delta) [Steve French]. > > It looks like you're including this with *each* time? But surely > there's no filesystem with different granularity (say) for ctime than > for mtime. I put it in each time struct to use up the hole there. I could, I suppose, split tv_sec from tv_nsec to get rid of the holes and then put the granularity separately. That means that someone who wanted both the tv_sec and tv_nsec would have to fish them out separately, but that's probably okay. I could even make the granularity bigger then, to allow for the possibility of having a granularity >4s, but I don't know of anywhere that requires a gran >2. > Also, nfsd will want only one time_delta, not one for each time. time_delta? Is that the same as granularity? > Note also we need to document carefully what this means: I think it > should be the granularity that the filesystem is capable of > representing, but people are sometimes surprised to find out that the > actual time source is usually more coarse-grained than that. Yeah, but the latter is something you may not be able to determine, and may indeed change over time (say someone updates the server kernel to one with a more fine-grained software clock). Also, for a network fs, it may depend on the client that happened to set that time last. David

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by David Howells

Andreas Dilger <adilger(a)dilger.ca> wrote: > > The idea was initially proposed as a set of xattrs that could be > > retrieved with getxattr(), but the general preferance proved to be > > for new syscalls with an extended stat structure. > > I would comment that it was the opposite. It was originally a > stat()-like extension that degraded into a messy getxattr() mess. Ummm... No, my first attempt was definitely through getxattr(). You even commented on it. > > The fields in struct xstat come in a number of classes: > > > > (0) st_dev, st_blksize, st_information. > > > > These are local data and are always available. > > For the extra two bits it would cost us, I don't think st_blksize > and st_information should always be returned. Fair enough. > st_blksize may be variable for a distributed filesystem, I wonder if there's a way to make this explicit - or is it something that if the bit isn't set, you can't use the value in st_blksize. I wonder if this value always has to be non-zero to make sure existing stat() doesn't explode. > and some of the fields in st_information (offline) may not be free to access > either. True. David

April 26, 2012

Re: [3/3] d3dx9: Implement conversion from DDS pixel format to D3DFORMAT.

by Matteo Bruni

Il 26 aprile 2012 11:47, Józef Kucia <joseph.kucia(a)gmail.com> ha scritto: > static D3DFORMAT dds_pixel_format_to_d3dformat(const struct dds_pixel_format *pixel_format) > { > - FIXME("Pixel format conversion not implemented.\n"); > + if (pixel_format->flags & DDS_PF_FOURCC) > + return dds_fourcc_to_d3dformat(pixel_format->fourcc); > + else if (pixel_format->flags & DDS_PF_RGB) > + return dds_rgb_to_d3dformat(pixel_format); > + else if (pixel_format->flags & DDS_PF_LUMINANCE) > + return dds_luminance_to_d3dformat(pixel_format); > + else if (pixel_format->flags & DDS_PF_ALPHA_ONLY) > + return dds_alpha_to_d3dformat(pixel_format); You don't need all those 'else's, the 'return's imply that you get there only when the 'if' condition isn't true. The same applies in other areas of this patch. I don't mind much, but since you have to resend the series anyway...

April 26, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Henri Verbeet

On 26 April 2012 12:13, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > On Thu, Apr 26, 2012 at 12:04 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> Is there no header that should define these? > > These structures and defines seem to be defined only in a D3D sample > "DDS without D3DX". > I guess that's ok then.

April 26, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Józef Kucia

On Thu, Apr 26, 2012 at 12:04 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > Is there no header that should define these? These structures and defines seem to be defined only in a D3D sample "DDS without D3DX".

April 26, 2012

Re: [2/3] d3dx9: Add partial DDS support implementation for D3DXGetImageInfo functions.

by Henri Verbeet

On 26 April 2012 11:47, Józef Kucia <joseph.kucia(a)gmail.com> wrote: > +static HRESULT get_image_info_from_dds(LPCVOID buffer, DWORD length, D3DXIMAGE_INFO *info) Please avoid types like LPCVOID.

April 26, 2012

Re: [1/3] d3dx9: Define DDS structures.

by Henri Verbeet

Is there no header that should define these?

April 26, 2012

Re: [PATCH 1/2] amstream: Add stubbed implementation of DirectDrawStreamSample. (try 4)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18050 Your paranoid android. === WVISTAADM (32 bit amstream) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

April 26, 2012

Re: gdiplus: GdipDrawString is not supposed to use the layout rectangle for clipping. Take 2.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > There is a dedicated clip region in the graphics object. Please ignore that patch or mark it as rejected, the real problem has been fixed by 9b5b04c1c1a7b32dd3e1e453b6d739082c4ccede. -- Dmitry.

April 25, 2012

Re: [PATCH 1/2] amstream: Add stubbed implementation of DirectDrawStreamSample. (try 3)

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > Try3: Put sample stuff in stream_sample.c > Try2: Fix QueryInterface. It was better without creating a new file. -- Alexandre Julliard julliard(a)winehq.org

April 25, 2012

Re: [PATCH 1/4] make_unicode: Create tables with data needed by nameprep algorithm

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > + dump_nameprep_range($INPUT, $nameprep_flags{"unassigned"}, \@flags_table) if (/A.1/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.1.2/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.2.2/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.3/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.4/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.5/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.6/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.7/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.8/); > + dump_nameprep_range($INPUT, $nameprep_flags{"prohibited"}, \@flags_table) if (/C.9/); > + dump_nameprep_range($INPUT, $nameprep_flags{"bidi_ral"}, \@flags_table) if (/D.1/); > + dump_nameprep_range($INPUT, $nameprep_flags{"bidi_l"}, \@flags_table) if (/D.2/); > + > + dump_nameprep_map($INPUT, \@mapping_table) if (/B.1/); > + dump_nameprep_map($INPUT, \@mapping_table) if (/B.2/); These names are confusing, the functions are loading data not dumping it. > + for (my $i = 0; $i < 65536; $i++) > + { > + next unless defined $flags_table[$i]; > + $flags_table[$i] += $i; > + } > + > + open OUTPUT,">$filename.new" or die "Cannot create $filename"; > + print "Building $filename\n"; > + print OUTPUT "/* Nameprep algorithm related data */\n"; > + print OUTPUT "/* generated from $STRINGPREP */\n"; > + print OUTPUT "/* DO NOT EDIT!! */\n\n"; > + print OUTPUT "#include \"wine/unicode.h\"\n\n"; > + DUMP_CASE_TABLE( "nameprep_char_type", @flags_table ); It doesn't make sense to use a case table for this, it's just flags. -- Alexandre Julliard julliard(a)winehq.org

April 25, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by Andreas Dilger

On 2012-04-24, at 4:29 PM, J. Bruce Fields wrote: > On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote: >> (11) Include granularity fields in the time data to indicate the >> granularity of each of the times (NFSv4 time_delta) [Steve French]. > > It looks like you're including this with *each* time? But surely > there's no filesystem with different granularity (say) for ctime than > for mtime. Also, nfsd will want only one time_delta, not one for each > time. I suspect the main reason for having a separate time_delta per timestamp is to use the extra 32-bit field in the timestamp structs. Since those structs have a 64-bit + 32-bit field, it would be messy to pack them, and leaving the spare bytes unused and adding an additional field for the granularity would just increase the struct size. > Note also we need to document carefully what this means: I think it > should be the granularity that the filesystem is capable of > representing, but people are sometimes surprised to find out that the > actual time source is usually more coarse-grained than that. > > --b. > >> >> (12) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. >> >> (13) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer, >> Michael Kerrisk]. >> >> (14) Spare space, request flags and information flags are provided for future >> expansion. >> >> >> The following structures are defined for the use of these new system calls: >> >> struct xstat_dev { >> uint32_t major, minor; >> }; >> >> struct xstat_time { >> uint64_t tv_sec; >> uint32_t tv_nsec; >> uint32_t tv_granularity; >> }; >> >> struct xstat { >> uint32_t st_mask; >> uint32_t st_mode; >> uint32_t st_nlink; >> uint32_t st_uid; >> uint32_t st_gid; >> uint32_t st_information; >> uint32_t st_ioc_flags; >> uint32_t st_blksize; >> struct xstat_dev st_rdev; >> struct xstat_dev st_dev; >> struct xstat_time st_atime; >> struct xstat_time st_btime; >> struct xstat_time st_ctime; >> struct xstat_time st_mtime; >> uint64_t st_ino; >> uint64_t st_size; >> uint64_t st_blocks; >> uint64_t st_gen; >> uint64_t st_version; >> uint8_t st_volume_id[16]; >> uint64_t __spares[11]; >> }; >> >> where st_information is local system information about the file, st_btime is >> the file creation time, st_gen is the inode generation (i_generation), >> st_data_version is the data version number (i_version), st_ioc_flags is the >> flags from FS_IOC_GETFLAGS, st_volume_id is where the volume identified is >> stored, st_result_mask is a bitmask indicating the data provided and __spares[] >> are where as-yet undefined fields can be placed. >> >> The defined bits in request_mask and st_mask are: >> >> XSTAT_MODE Want/got st_mode >> XSTAT_NLINK Want/got st_nlink >> XSTAT_UID Want/got st_uid >> XSTAT_GID Want/got st_gid >> XSTAT_RDEV Want/got st_rdev >> XSTAT_ATIME Want/got st_atime >> XSTAT_MTIME Want/got st_mtime >> XSTAT_CTIME Want/got st_ctime >> XSTAT_INO Want/got st_ino >> XSTAT_SIZE Want/got st_size >> XSTAT_BLOCKS Want/got st_blocks >> XSTAT_BASIC_STATS [The stuff in the normal stat struct] >> XSTAT_IOC_FLAGS Want/got FS_IOC_GETFLAGS >> XSTAT_BTIME Want/got st_btime >> XSTAT_GEN Want/got st_gen >> XSTAT_VERSION Want/got st_data_version >> XSTAT_VOLUME_ID Want/got st_volume_id >> XSTAT_ALL_STATS [All currently available stuff] >> >> The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra flags >> that might be supplied by the filesystem. Note that Ext4 returns flags outside >> of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS. Should >> {EXT4,FS}_FL_USER_VISIBLE be extended to cover them? Or should the extra flags >> be suppressed? >> >> The defined bits in the st_information field give local system data on a file, >> how it is accessed, where it is and what it does: >> >> XSTAT_INFO_ENCRYPTED File is encrypted >> XSTAT_INFO_TEMPORARY File is temporary (NTFS/CIFS/deleted) >> XSTAT_INFO_FABRICATED File was made up by filesystem >> XSTAT_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) >> XSTAT_INFO_REMOTE File is remote >> XSTAT_INFO_OFFLINE File is offline (CIFS) >> XSTAT_INFO_AUTOMOUNT Dir is automount trigger >> XSTAT_INFO_AUTODIR Dir provides unlisted automounts >> XSTAT_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details >> XSTAT_INFO_HAS_ACL File has an ACL of some sort >> XSTAT_INFO_REPARSE_POINT File is reparse point (NTFS/CIFS) >> XSTAT_INFO_HIDDEN File is marked hidden (DOS+) >> XSTAT_INFO_SYSTEM File is marked system (DOS+) >> XSTAT_INFO_ARCHIVE File is marked archive (DOS+) >> >> These are for the use of GUI tools that might want to mark files specially, >> depending on what they are. I've tried not to provide overlap with >> st_ioc_flags where something usable exists there. Should Hidden, System and >> Archive flags be associated with ioc_flags, perhaps with ioc_flags extended to >> 64-bits? >> >> >> The system calls are: >> >> ssize_t ret = xstat(int dfd, >> const char *filename, >> unsigned int flags, >> unsigned int mask, >> struct xstat *buffer); >> >> ssize_t ret = fxstat(unsigned fd, >> unsigned int flags, >> unsigned int mask, >> struct xstat *buffer); >> >> >> The dfd, filename, flags and fd parameters indicate the file to query. There >> is no equivalent of lstat() as that can be emulated with xstat() by passing >> AT_SYMLINK_NOFOLLOW in flags. >> >> AT_FORCE_ATTR_SYNC can also be set in flags. This will require a network >> filesystem to synchronise its attributes with the server. >> >> mask is a bitmask indicating the fields in struct xstat that are of interest to >> the caller. The user should set this to XSTAT__BASIC_STATS to get the >> basic set returned by stat(). >> >> Should there just be one xstat() syscall that does fxstat() if filename is NULL? >> >> The fields in struct xstat come in a number of classes: >> >> (0) st_dev, st_blksize, st_information. >> >> These are local data and are always available. >> >> (1) st_mode, st_nlinks, st_uid, st_gid, st_[amc]time, st_ino, st_size, >> st_blocks. >> >> These will be returned whether the caller asks for them or not. The >> corresponding bits in result_mask will be set to indicate their presence. >> >> If the caller didn't ask for them, then they may be approximated. For >> example, NFS won't waste any time updating them from the server, unless as >> a byproduct of updating something requested. >> >> If the values don't actually exist for the underlying object (such as UID >> or GID on a DOS file), then the bit won't be set in the result_mask, even >> if the caller asked for the value and the returned value will be a >> fabrication. >> >> (2) st_rdev. >> >> As for class (1), but this won't be returned if the file is not a blockdev >> or chardev. The bit will be cleared if the value is not returned. >> >> (3) File creation time (st_btime), inode generation (st_gen), data version >> (st_version), volume_id (st_volume_id) and inode flags (st_ioc_flags). >> >> These will be returned if available whether the caller asked for them or >> not. The corresponding bits in result_mask will be set or cleared as >> appropriate to indicate their presence. >> >> If the caller didn't ask for them, then they may be approximated. For >> example, NFS won't waste any time updating them from the server, unless >> as a byproduct of updating something requested. >> >> At the moment, this will only work on x86_64 and i386 as it requires system >> calls to be wired up. >> >> >> ======= >> TESTING >> ======= >> >> The following test program can be used to test the xstat system call: >> >> /* Test the xstat() system call >> * >> * Copyright (C) 2010 Red Hat, Inc. All Rights Reserved. >> * Written by David Howells (dhowells(a)redhat.com) >> * >> * This program is free software; you can redistribute it and/or >> * modify it under the terms of the GNU General Public Licence >> * as published by the Free Software Foundation; either version >> * 2 of the Licence, or (at your option) any later version. >> */ >> >> #define _GNU_SOURCE >> #define _ATFILE_SOURCE >> #include <stdio.h> >> #include <stdlib.h> >> #include <string.h> >> #include <unistd.h> >> #include <fcntl.h> >> #include <time.h> >> #include <sys/syscall.h> >> #include <sys/stat.h> >> #include <sys/types.h> >> >> #define AT_NO_AUTOMOUNT 0x800 >> #define AT_FORCE_ATTR_SYNC 0x2000 >> >> #define XSTAT_MODE 0x00000001U >> #define XSTAT_NLINK 0x00000002U >> #define XSTAT_UID 0x00000004U >> #define XSTAT_GID 0x00000008U >> #define XSTAT_RDEV 0x00000010U >> #define XSTAT_ATIME 0x00000020U >> #define XSTAT_MTIME 0x00000040U >> #define XSTAT_CTIME 0x00000080U >> #define XSTAT_INO 0x00000100U >> #define XSTAT_SIZE 0x00000200U >> #define XSTAT_BLOCKS 0x00000400U >> #define XSTAT_BASIC_STATS 0x000007ffU >> #define XSTAT_BTIME 0x00000800U >> #define XSTAT_GEN 0x00001000U >> #define XSTAT_VERSION 0x00002000U >> #define XSTAT_IOC_FLAGS 0x00004000U >> #define XSTAT_VOLUME_ID 0x00008000U >> #define XSTAT_ALL_STATS 0x0000ffffU >> >> struct xstat_dev { >> uint32_t major; >> uint32_t minor; >> }; >> >> struct xstat_time { >> uint64_t tv_sec; >> uint32_t tv_nsec; >> uint32_t tv_granularity; >> }; >> >> struct xstat { >> uint32_t st_mask; >> uint32_t st_mode; >> uint32_t st_nlink; >> uint32_t st_uid; >> uint32_t st_gid; >> uint32_t st_information; >> uint32_t st_ioc_flags; >> uint32_t st_blksize; >> struct xstat_dev st_rdev; >> struct xstat_dev st_dev; >> struct xstat_time st_atim; >> struct xstat_time st_btim; >> struct xstat_time st_ctim; >> struct xstat_time st_mtim; >> uint64_t st_ino; >> uint64_t st_size; >> uint64_t st_blksize; >> uint64_t st_blocks; >> uint64_t st_gen; >> uint64_t st_version; >> uint64_t st_volume_id[16]; >> uint64_t st_spares[11]; >> }; >> >> #define XSTAT_INFO_ENCRYPTED 0x00000001U >> #define XSTAT_INFO_TEMPORARY 0x00000002U >> #define XSTAT_INFO_FABRICATED 0x00000004U >> #define XSTAT_INFO_KERNEL_API 0x00000008U >> #define XSTAT_INFO_REMOTE 0x00000010U >> #define XSTAT_INFO_OFFLINE 0x00000020U >> #define XSTAT_INFO_AUTOMOUNT 0x00000040U >> #define XSTAT_INFO_AUTODIR 0x00000080U >> #define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U >> #define XSTAT_INFO_HAS_ACL 0x00000200U >> #define XSTAT_INFO_REPARSE_POINT 0x00000400U >> #define XSTAT_INFO_HIDDEN 0x00000800U >> #define XSTAT_INFO_SYSTEM 0x00001000U >> #define XSTAT_INFO_ARCHIVE 0x00002000U >> >> #define __NR_xstat 312 >> #define __NR_fxstat 313 >> >> static __attribute__((unused)) >> ssize_t xstat(int dfd, const char *filename, unsigned flags, >> unsigned int mask, struct xstat *buffer) >> { >> return syscall(__NR_xstat, dfd, filename, flags, mask, buffer); >> } >> >> static __attribute__((unused)) >> ssize_t fxstat(int fd, unsigned flags, >> unsigned int mask, struct xstat *buffer) >> { >> return syscall(__NR_fxstat, fd, flags, mask, buffer); >> } >> >> static void print_time(const char *field, const struct xstat_time *xstm) >> { >> struct tm tm; >> time_t tim; >> char buffer[100]; >> int len; >> >> tim = xstm->tv_sec; >> if (!localtime_r(&tim, &tm)) { >> perror("localtime_r"); >> exit(1); >> } >> len = strftime(buffer, 100, "%F %T", &tm); >> if (len == 0) { >> perror("strftime"); >> exit(1); >> } >> printf("%s", field); >> fwrite(buffer, 1, len, stdout); >> printf(".%09u", xstm->tv_nsec); >> len = strftime(buffer, 100, "%z", &tm); >> if (len == 0) { >> perror("strftime2"); >> exit(1); >> } >> fwrite(buffer, 1, len, stdout); >> printf("\n"); >> } >> >> static void dump_xstat(struct xstat *xst) >> { >> char buffer[256], ft; >> >> printf("results=%x\n", xst->st_mask); >> >> printf(" "); >> if (xst->st_mask & XSTAT_SIZE) >> printf(" Size: %-15llu", (unsigned long long) xst->st_size); >> if (xst->st_mask & XSTAT_BLOCKS) >> printf(" Blocks: %-10llu", (unsigned long long) xst->st_blocks); >> printf(" IO Block: %-6llu ", (unsigned long long) xst->st_blksize); >> if (xst->st_mask & XSTAT_MODE) { >> switch (xst->st_mode & S_IFMT) { >> case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break; >> case S_IFCHR: printf(" character special file\n"); ft = 'c'; break; >> case S_IFDIR: printf(" directory\n"); ft = 'd'; break; >> case S_IFBLK: printf(" block special file\n"); ft = 'b'; break; >> case S_IFREG: printf(" regular file\n"); ft = '-'; break; >> case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break; >> case S_IFSOCK: printf(" socket\n"); ft = 's'; break; >> default: >> printf("unknown type (%o)\n", xst->st_mode & S_IFMT); >> ft = '?'; >> break; >> } >> } >> >> sprintf(buffer, "%02x:%02x", xst->st_dev.major, xst->st_dev.minor); >> printf("Device: %-15s", buffer); >> if (xst->st_mask & XSTAT_INO) >> printf(" Inode: %-11llu", (unsigned long long) xst->st_ino); >> if (xst->st_mask & XSTAT_SIZE) >> printf(" Links: %-5u", xst->st_nlink); >> if (xst->st_mask & XSTAT_RDEV) >> printf(" Device type: %u,%u", >> xst->st_rdev.major, xst->st_rdev.minor); >> printf("\n"); >> >> if (xst->st_mask & XSTAT_MODE) >> printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", >> xst->st_mode & 07777, >> ft, >> xst->st_mode & S_IRUSR ? 'r' : '-', >> xst->st_mode & S_IWUSR ? 'w' : '-', >> xst->st_mode & S_IXUSR ? 'x' : '-', >> xst->st_mode & S_IRGRP ? 'r' : '-', >> xst->st_mode & S_IWGRP ? 'w' : '-', >> xst->st_mode & S_IXGRP ? 'x' : '-', >> xst->st_mode & S_IROTH ? 'r' : '-', >> xst->st_mode & S_IWOTH ? 'w' : '-', >> xst->st_mode & S_IXOTH ? 'x' : '-'); >> if (xst->st_mask & XSTAT_UID) >> printf("Uid: %d \n", xst->st_uid); >> if (xst->st_mask & XSTAT_GID) >> printf("Gid: %u\n", xst->st_gid); >> >> if (xst->st_mask & XSTAT_ATIME) >> print_time("Access: ", &xst->st_atim); >> if (xst->st_mask & XSTAT_MTIME) >> print_time("Modify: ", &xst->st_mtim); >> if (xst->st_mask & XSTAT_CTIME) >> print_time("Change: ", &xst->st_ctim); >> if (xst->st_mask & XSTAT_BTIME) >> print_time("Create: ", &xst->st_btim); >> >> if (xst->st_mask & XSTAT_GEN) >> printf("Inode version: %llxh\n", (unsigned long long) xst->st_gen); >> if (xst->st_mask & XSTAT_VERSION) >> printf("Data version: %llxh\n", (unsigned long long) xst->st_version); >> >> if (xst->st_mask & XSTAT_IOC_FLAGS) { >> unsigned char bits; >> int loop, byte; >> >> static char flag_representation[32 + 1] = >> /* FS_IOC_GETFLAGS flags: */ >> "????????" /* 31-24 0x00000000-ff000000 */ >> "????ehTD" /* 23-16 0x00000000-00ff0000 */ >> "tj?IE?XZ" /* 15- 8 0x00000000-0000ff00 */ >> "AdaiScus" /* 7- 0 0x00000000-000000ff */ >> ; >> >> printf("Inode flags: %08x (", xst->st_ioc_flags); >> for (byte = 32 - 8; byte >= 0; byte -= 8) { >> bits = xst->st_ioc_flags >> byte; >> for (loop = 7; loop >= 0; loop--) { >> int bit = byte + loop; >> >> if (bits & 0x80) >> putchar(flag_representation[31 - bit]); >> else >> putchar('-'); >> bits <<= 1; >> } >> if (byte) >> putchar(' '); >> } >> printf(")\n"); >> } >> >> if (xst->st_information) { >> unsigned char bits; >> int loop, byte; >> >> static char info_representation[32 + 1] = >> /* XSTAT_INFO_ flags: */ >> "????????" /* 31-24 0x00000000-ff000000 */ >> "????????" /* 23-16 0x00000000-00ff0000 */ >> "??ASHRan" /* 15- 8 0x00000000-0000ff00 */ >> "dmorkfte" /* 7- 0 0x00000000-000000ff */ >> ; >> >> printf("Information: %08x (", xst->st_information); >> for (byte = 32 - 8; byte >= 0; byte -= 8) { >> bits = xst->st_information >> byte; >> for (loop = 7; loop >= 0; loop--) { >> int bit = byte + loop; >> >> if (bits & 0x80) >> putchar(info_representation[31 - bit]); >> else >> putchar('-'); >> bits <<= 1; >> } >> if (byte) >> putchar(' '); >> } >> printf(")\n"); >> } >> >> if (xst->st_mask & XSTAT_VOLUME_ID) { >> int loop; >> printf("Volume ID: "); >> for (loop = 0; loop < sizeof(xst->st_volume_id); loop++) { >> printf("%02x", xst->st_volume_id[loop]); >> if (loop == 7) >> printf("-"); >> } >> printf("\n"); >> } >> } >> >> void dump_hex(unsigned long long *data, int from, int to) >> { >> unsigned offset, print_offset = 1, col = 0; >> >> from /= 8; >> to = (to + 7) / 8; >> >> for (offset = from; offset < to; offset++) { >> if (print_offset) { >> printf("%04x: ", offset * 8); >> print_offset = 0; >> } >> printf("%016llx", data[offset]); >> col++; >> if ((col & 3) == 0) { >> printf("\n"); >> print_offset = 1; >> } else { >> printf(" "); >> } >> } >> >> if (!print_offset) >> printf("\n"); >> } >> >> int main(int argc, char **argv) >> { >> struct xstat xst; >> int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW; >> >> unsigned int mask = XSTAT_ALL_STATS; >> >> for (argv++; *argv; argv++) { >> if (strcmp(*argv, "-F") == 0) { >> atflag |= AT_FORCE_ATTR_SYNC; >> continue; >> } >> if (strcmp(*argv, "-L") == 0) { >> atflag &= ~AT_SYMLINK_NOFOLLOW; >> continue; >> } >> if (strcmp(*argv, "-O") == 0) { >> mask &= ~XSTAT_BASIC_STATS; >> continue; >> } >> if (strcmp(*argv, "-A") == 0) { >> atflag |= AT_NO_AUTOMOUNT; >> continue; >> } >> if (strcmp(*argv, "-R") == 0) { >> raw = 1; >> continue; >> } >> >> memset(&xst, 0xbf, sizeof(xst)); >> ret = xstat(AT_FDCWD, *argv, atflag, mask, &xst); >> printf("xstat(%s) = %d\n", *argv, ret); >> if (ret < 0) { >> perror(*argv); >> exit(1); >> } >> >> if (raw) >> dump_hex((unsigned long long *)&xst, 0, sizeof(xst)); >> >> dump_xstat(&xst); >> } >> return 0; >> } >> >> Just compile and run, passing it paths to the files you want to examine: >> >> [root(a)andromeda ~]# /tmp/xstat /proc/$$ >> xstat(/proc/2074) = 160 >> results=47ef >> Size: 0 Blocks: 0 IO Block: 1024 directory >> Device: 00:03 Inode: 9072 Links: 7 >> Access: (0555/dr-xr-xr-x) Uid: 0 >> Gid: 0 >> Access: 2010-07-14 16:50:46.609336272+0100 >> Modify: 2010-07-14 16:50:46.609336272+0100 >> Change: 2010-07-14 16:50:46.609336272+0100 >> Inode flags: 0000000100000000 (-------- -------- -------- -------S -------- -------- -------- --------) >> [root(a)andromeda ~]# /tmp/xstat /afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm >> xstat(/afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm) = 160 >> results=77ef >> Size: 5413882 Blocks: 0 IO Block: 4096 regular file >> Device: 00:15 Inode: 2288 Links: 1 >> Access: (0644/-rw-r--r--) Uid: 75338 >> Gid: 0 >> Access: 2008-11-05 19:47:22.000000000+0000 >> Modify: 2008-11-05 19:47:22.000000000+0000 >> Change: 2008-11-05 19:47:22.000000000+0000 >> Inode version: 795h >> Data version: 2h >> Inode flags: 0000000800000000 (-------- -------- -------- ----r--- -------- -------- -------- --------) >> >> Signed-off-by: David Howells <dhowells(a)redhat.com> >> --- >> >> arch/x86/syscalls/syscall_32.tbl | 2 >> arch/x86/syscalls/syscall_64.tbl | 2 >> fs/stat.c | 350 +++++++++++++++++++++++++++++++++++--- >> include/linux/fcntl.h | 1 >> include/linux/fs.h | 4 >> include/linux/stat.h | 126 +++++++++++++- >> include/linux/syscalls.h | 7 + >> 7 files changed, 461 insertions(+), 31 deletions(-) >> >> diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl >> index 29f9f05..980eb5a 100644 >> --- a/arch/x86/syscalls/syscall_32.tbl >> +++ b/arch/x86/syscalls/syscall_32.tbl >> @@ -355,3 +355,5 @@ >> 346 i386 setns sys_setns >> 347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv >> 348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev >> +349 i386 xstat sys_xstat >> +350 i386 fxstat sys_fxstat >> diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl >> index dd29a9e..7ae24bb 100644 >> --- a/arch/x86/syscalls/syscall_64.tbl >> +++ b/arch/x86/syscalls/syscall_64.tbl >> @@ -318,6 +318,8 @@ >> 309 common getcpu sys_getcpu >> 310 64 process_vm_readv sys_process_vm_readv >> 311 64 process_vm_writev sys_process_vm_writev >> +312 common xstat sys_xstat >> +313 common fxstat sys_fxstat >> # >> # x32-specific system call numbers start at 512 to avoid cache impact >> # for native 64-bit operation. >> diff --git a/fs/stat.c b/fs/stat.c >> index c733dc5..af3ef33 100644 >> --- a/fs/stat.c >> +++ b/fs/stat.c >> @@ -18,8 +18,20 @@ >> #include <asm/uaccess.h> >> #include <asm/unistd.h> >> >> +/** >> + * generic_fillattr - Fill in the basic attributes from the inode struct >> + * @inode: Inode to use as the source >> + * @stat: Where to fill in the attributes >> + * >> + * Fill in the basic attributes in the kstat structure from data that's to be >> + * found on the VFS inode structure. This is the default if no getattr inode >> + * operation is supplied. >> + */ >> void generic_fillattr(struct inode *inode, struct kstat *stat) >> { >> + struct super_block *sb = inode->i_sb; >> + u32 x; >> + >> stat->dev = inode->i_sb->s_dev; >> stat->ino = inode->i_ino; >> stat->mode = inode->i_mode; >> @@ -27,17 +39,61 @@ void generic_fillattr(struct inode *inode, struct kstat *stat) >> stat->uid = inode->i_uid; >> stat->gid = inode->i_gid; >> stat->rdev = inode->i_rdev; >> - stat->size = i_size_read(inode); >> - stat->atime = inode->i_atime; >> stat->mtime = inode->i_mtime; >> stat->ctime = inode->i_ctime; >> - stat->blksize = (1 << inode->i_blkbits); >> + stat->size = i_size_read(inode); >> stat->blocks = inode->i_blocks; >> -} >> + stat->blksize = (1 << inode->i_blkbits); >> >> + stat->result_mask |= XSTAT_BASIC_STATS & ~XSTAT_RDEV; >> + if (IS_NOATIME(inode)) >> + stat->result_mask &= ~XSTAT_ATIME; >> + else >> + stat->atime = inode->i_atime; >> + >> + if (S_ISREG(stat->mode) && stat->nlink == 0) >> + stat->information |= XSTAT_INFO_TEMPORARY; >> + if (IS_AUTOMOUNT(inode)) >> + stat->information |= XSTAT_INFO_AUTOMOUNT; >> + if (IS_POSIXACL(inode)) >> + stat->information |= XSTAT_INFO_HAS_ACL; >> + >> + /* if unset, assume 1s granularity */ >> + stat->tv_granularity = sb->s_time_gran ?: 1000000000U; >> + >> + if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode))) >> + stat->result_mask |= XSTAT_RDEV; >> + >> + x = ((u32*)&stat->volume_id)[0] = ((u32*)&sb->s_volume_id)[0]; >> + x |= ((u32*)&stat->volume_id)[1] = ((u32*)&sb->s_volume_id)[1]; >> + x |= ((u32*)&stat->volume_id)[2] = ((u32*)&sb->s_volume_id)[2]; >> + x |= ((u32*)&stat->volume_id)[3] = ((u32*)&sb->s_volume_id)[3]; >> + if (x) >> + stat->result_mask |= XSTAT_VOLUME_ID; >> +} >> EXPORT_SYMBOL(generic_fillattr); >> >> -int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) >> +/** >> + * vfs_xgetattr - Get the basic and extra attributes of a file >> + * @mnt: The mountpoint to which the dentry belongs >> + * @dentry: The file of interest >> + * @stat: Where to return the statistics >> + * >> + * Ask the filesystem for a file's attributes. The caller must have preset >> + * stat->request_mask and stat->query_flags to indicate what they want. >> + * >> + * If the file is remote, the filesystem can be forced to update the attributes >> + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags. >> + * >> + * Bits must have been set in stat->request_mask to indicate which attributes >> + * the caller wants retrieving. Any such attribute not requested may be >> + * returned anyway, but the value may be approximate, and, if remote, may not >> + * have been synchronised with the server. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry, >> + struct kstat *stat) >> { >> struct inode *inode = dentry->d_inode; >> int retval; >> @@ -46,64 +102,184 @@ int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) >> if (retval) >> return retval; >> >> + stat->result_mask = 0; >> + stat->information = 0; >> + stat->ioc_flags = 0; >> if (inode->i_op->getattr) >> return inode->i_op->getattr(mnt, dentry, stat); >> >> generic_fillattr(inode, stat); >> return 0; >> } >> +EXPORT_SYMBOL(vfs_xgetattr); >> >> +/** >> + * vfs_getattr - Get the basic attributes of a file >> + * @mnt: The mountpoint to which the dentry belongs >> + * @dentry: The file of interest >> + * @stat: Where to return the statistics >> + * >> + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't >> + * forced to update its files from the backing store. Only the basic set of >> + * attributes will be retrieved; anyone wanting more must use vfs_getxattr(), >> + * as must anyone who wants to force attributes to be sync'd with the server. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) >> +{ >> + stat->query_flags = 0; >> + stat->request_mask = XSTAT_BASIC_STATS; >> + return vfs_xgetattr(mnt, dentry, stat); >> +} >> EXPORT_SYMBOL(vfs_getattr); >> >> -int vfs_fstat(unsigned int fd, struct kstat *stat) >> +/** >> + * vfs_fxstat - Get basic and extra attributes by file descriptor >> + * @fd: The file descriptor refering to the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xgetattr(). The main difference is >> + * that it uses a file descriptor to determine the file location. >> + * >> + * The caller must have preset stat->query_flags and stat->request_mask as for >> + * vfs_xgetattr(). >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_fxstat(unsigned int fd, struct kstat *stat) >> { >> struct file *f = fget(fd); >> int error = -EBADF; >> >> + if (stat->query_flags & ~KSTAT_QUERY_FLAGS) >> + return -EINVAL; >> if (f) { >> - error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat); >> + error = vfs_xgetattr(f->f_path.mnt, f->f_path.dentry, stat); >> fput(f); >> } >> return error; >> } >> +EXPORT_SYMBOL(vfs_fxstat); >> + >> +/** >> + * vfs_fstat - Get basic attributes by file descriptor >> + * @fd: The file descriptor refering to the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_getattr(). The main difference is >> + * that it uses a file descriptor to determine the file location. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_fstat(unsigned int fd, struct kstat *stat) >> +{ >> + stat->query_flags = 0; >> + stat->request_mask = XSTAT_BASIC_STATS; >> + return vfs_fxstat(fd, stat); >> +} >> EXPORT_SYMBOL(vfs_fstat); >> >> -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, >> - int flag) >> +/** >> + * vfs_xstat - Get basic and extra attributes by filename >> + * @dfd: A file descriptor representing the base dir for a relative filename >> + * @filename: The name of the file of interest >> + * @flags: Flags to control the query >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xgetattr(). The main difference is >> + * that it uses a filename and base directory to determine the file location. >> + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a >> + * symlink at the given name from being referenced. >> + * >> + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The >> + * flags are also used to load up stat->query_flags. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_xstat(int dfd, const char __user *filename, int flags, >> + struct kstat *stat) >> { >> struct path path; >> - int error = -EINVAL; >> - int lookup_flags = 0; >> + int error, lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT; >> >> - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | >> - AT_EMPTY_PATH)) != 0) >> - goto out; >> + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | >> + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0) >> + return -EINVAL; >> >> - if (!(flag & AT_SYMLINK_NOFOLLOW)) >> - lookup_flags |= LOOKUP_FOLLOW; >> - if (flag & AT_EMPTY_PATH) >> + if (flags & AT_SYMLINK_NOFOLLOW) >> + lookup_flags &= ~LOOKUP_FOLLOW; >> + if (flags & AT_NO_AUTOMOUNT) >> + lookup_flags &= ~LOOKUP_AUTOMOUNT; >> + if (flags & AT_EMPTY_PATH) >> lookup_flags |= LOOKUP_EMPTY; >> >> + stat->query_flags = flags & KSTAT_QUERY_FLAGS; >> error = user_path_at(dfd, filename, lookup_flags, &path); >> - if (error) >> - goto out; >> - >> - error = vfs_getattr(path.mnt, path.dentry, stat); >> - path_put(&path); >> -out: >> + if (!error) { >> + error = vfs_xgetattr(path.mnt, path.dentry, stat); >> + path_put(&path); >> + } >> return error; >> } >> +EXPORT_SYMBOL(vfs_xstat); >> + >> +/** >> + * vfs_fstatat - Get basic attributes by filename >> + * @dfd: A file descriptor representing the base dir for a relative filename >> + * @filename: The name of the file of interest >> + * @flags: Flags to control the query >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xstat(). The difference is that it >> + * preselects basic stats only. The flags are used to load up >> + * stat->query_flags in addition to indicating symlink handling during path >> + * resolution. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, >> + int flags) >> +{ >> + stat->request_mask = XSTAT_BASIC_STATS; >> + return vfs_xstat(dfd, filename, flags, stat); >> +} >> EXPORT_SYMBOL(vfs_fstatat); >> >> -int vfs_stat(const char __user *name, struct kstat *stat) >> +/** >> + * vfs_stat - Get basic attributes by filename >> + * @filename: The name of the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xstat(). The difference is that it >> + * preselects basic stats only, terminal symlinks are followed regardless and a >> + * remote filesystem can't be forced to query the server. If such is desired, >> + * vfs_xstat() should be used instead. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> +int vfs_stat(const char __user *filename, struct kstat *stat) >> { >> - return vfs_fstatat(AT_FDCWD, name, stat, 0); >> + stat->request_mask = XSTAT_BASIC_STATS; >> + return vfs_xstat(AT_FDCWD, filename, 0, stat); >> } >> EXPORT_SYMBOL(vfs_stat); >> >> +/** >> + * vfs_stat - Get basic attributes by filename, without following terminal symlink >> + * @filename: The name of the file of interest >> + * @stat: The result structure to fill in. >> + * >> + * This function is a wrapper around vfs_xstat(). The difference is that it >> + * preselects basic stats only, terminal symlinks are note followed regardless >> + * and a remote filesystem can't be forced to query the server. If such is >> + * desired, vfs_xstat() should be used instead. >> + * >> + * 0 will be returned on success, and a -ve error code if unsuccessful. >> + */ >> int vfs_lstat(const char __user *name, struct kstat *stat) >> { >> - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW); >> + return vfs_xstat(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat); >> } >> EXPORT_SYMBOL(vfs_lstat); >> >> @@ -118,7 +294,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta >> { >> static int warncount = 5; >> struct __old_kernel_stat tmp; >> - >> + >> if (warncount > 0) { >> warncount--; >> printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n", >> @@ -143,7 +319,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta >> #if BITS_PER_LONG == 32 >> if (stat->size > MAX_NON_LFS) >> return -EOVERFLOW; >> -#endif >> +#endif >> tmp.st_size = stat->size; >> tmp.st_atime = stat->atime.tv_sec; >> tmp.st_mtime = stat->mtime.tv_sec; >> @@ -225,7 +401,7 @@ static int cp_new_stat(struct kstat *stat, struct stat __user *statbuf) >> #if BITS_PER_LONG == 32 >> if (stat->size > MAX_NON_LFS) >> return -EOVERFLOW; >> -#endif >> +#endif >> tmp.st_size = stat->size; >> tmp.st_atime = stat->atime.tv_sec; >> tmp.st_mtime = stat->mtime.tv_sec; >> @@ -412,6 +588,122 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename, >> } >> #endif /* __ARCH_WANT_STAT64 */ >> >> +/* >> + * Get the xstat parameters if supplied >> + */ >> +static int xstat_get_params(unsigned int mask, struct xstat __user *buffer, >> + struct kstat *stat) >> +{ >> + memset(stat, 0xde, sizeof(*stat)); // DEBUGGING >> + >> + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer))) >> + return -EFAULT; >> + >> + stat->request_mask = mask & XSTAT_ALL_STATS; >> + stat->result_mask = 0; >> + return 0; >> +} >> + >> +/* >> + * Set the xstat results. >> + * >> + * If the buffer size was 0, we just return the size of the buffer needed to >> + * return the full result. >> + * >> + * If bufsize indicates a buffer of insufficient size to hold the full result, >> + * we return -E2BIG. >> + * >> + * Otherwise we copy the extended stats to userspace and return the amount of >> + * data written into the buffer (or -EFAULT). >> + */ >> +static long xstat_set_result(struct kstat *stat, struct xstat __user *buffer) >> +{ >> + u32 mask = stat->result_mask, gran = stat->tv_granularity; >> + >> +#define __put_timestamp(kts, uts) ( \ >> + __put_user(kts.tv_sec, uts.tv_sec ) || \ >> + __put_user(kts.tv_nsec, uts.tv_nsec ) || \ >> + __put_user(gran, uts.tv_granularity )) >> + >> + /* clear out anything we're not returning */ >> + if (!(mask & XSTAT_IOC_FLAGS)) >> + stat->ioc_flags = 0; >> + if (!(mask & XSTAT_BTIME)) >> + memset(&stat->btime, 0, sizeof(stat->btime)); >> + if (!(mask & XSTAT_GEN)) >> + stat->gen = 0; >> + if (!(mask & XSTAT_VERSION)) >> + stat->version = 0; >> + if (!(mask & XSTAT_VOLUME_ID)) >> + memset(&stat->volume_id, 0, sizeof(stat->volume_id)); >> + >> + /* transfer the results */ >> + if (__put_user(mask, &buffer->st_mask ) || >> + __put_user(stat->mode, &buffer->st_mode ) || >> + __put_user(stat->nlink, &buffer->st_nlink ) || >> + __put_user(stat->uid, &buffer->st_uid ) || >> + __put_user(stat->gid, &buffer->st_gid ) || >> + __put_user(stat->information, &buffer->st_information ) || >> + __put_user(stat->ioc_flags, &buffer->st_ioc_flags ) || >> + __put_user(stat->blksize, &buffer->st_blksize ) || >> + __put_user(MAJOR(stat->rdev), &buffer->st_rdev.major ) || >> + __put_user(MINOR(stat->rdev), &buffer->st_rdev.minor ) || >> + __put_user(MAJOR(stat->dev), &buffer->st_dev.major ) || >> + __put_user(MINOR(stat->dev), &buffer->st_dev.minor ) || >> + __put_timestamp(stat->atime, &buffer->st_atime ) || >> + __put_timestamp(stat->btime, &buffer->st_btime ) || >> + __put_timestamp(stat->ctime, &buffer->st_ctime ) || >> + __put_timestamp(stat->mtime, &buffer->st_mtime ) || >> + __put_user(stat->ino, &buffer->st_ino ) || >> + __put_user(stat->size, &buffer->st_size ) || >> + __put_user(stat->blocks, &buffer->st_blocks ) || >> + __put_user(stat->gen, &buffer->st_gen ) || >> + __put_user(stat->version, &buffer->st_version ) || >> + __copy_to_user(&buffer->st_volume_id, &stat->volume_id, >> + sizeof(buffer->st_volume_id) ) || >> + __clear_user(&buffer->__spares, sizeof(buffer->__spares))) >> + return -EFAULT; >> + return 0; >> +} >> + >> +/* >> + * System call to get extended stats by path >> + */ >> +SYSCALL_DEFINE5(xstat, >> + int, dfd, const char __user *, filename, unsigned, flags, >> + unsigned int, mask, struct xstat __user *, buffer) >> +{ >> + struct kstat stat; >> + int error; >> + >> + error = xstat_get_params(mask, buffer, &stat); >> + if (error != 0) >> + return error; >> + error = vfs_xstat(dfd, filename, flags, &stat); >> + if (error) >> + return error; >> + return xstat_set_result(&stat, buffer); >> +} >> + >> +/* >> + * System call to get extended stats by file descriptor >> + */ >> +SYSCALL_DEFINE4(fxstat, unsigned int, fd, unsigned int, flags, >> + unsigned int, mask, struct xstat __user *, buffer) >> +{ >> + struct kstat stat; >> + int error; >> + >> + error = xstat_get_params(mask, buffer, &stat); >> + if (error < 0) >> + return error; >> + stat.query_flags = flags; >> + error = vfs_fxstat(fd, &stat); >> + if (error) >> + return error; >> + return xstat_set_result(&stat, buffer); >> +} >> + >> /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */ >> void __inode_add_bytes(struct inode *inode, loff_t bytes) >> { >> diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h >> index f550f89..faa9e5d 100644 >> --- a/include/linux/fcntl.h >> +++ b/include/linux/fcntl.h >> @@ -47,6 +47,7 @@ >> #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ >> #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */ >> #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ >> +#define AT_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ >> >> #ifdef __KERNEL__ >> >> diff --git a/include/linux/fs.h b/include/linux/fs.h >> index 8de6755..ec6c62e 100644 >> --- a/include/linux/fs.h >> +++ b/include/linux/fs.h >> @@ -1467,6 +1467,7 @@ struct super_block { >> >> char s_id[32]; /* Informational name */ >> u8 s_uuid[16]; /* UUID */ >> + unsigned char s_volume_id[16]; /* Volume identifier */ >> >> void *s_fs_info; /* Filesystem private info */ >> unsigned int s_max_links; >> @@ -2470,6 +2471,7 @@ extern const struct inode_operations page_symlink_inode_operations; >> extern int generic_readlink(struct dentry *, char __user *, int); >> extern void generic_fillattr(struct inode *, struct kstat *); >> extern int vfs_getattr(struct vfsmount *, struct dentry *, struct kstat *); >> +extern int vfs_xgetattr(struct vfsmount *, struct dentry *, struct kstat *); >> void __inode_add_bytes(struct inode *inode, loff_t bytes); >> void inode_add_bytes(struct inode *inode, loff_t bytes); >> void inode_sub_bytes(struct inode *inode, loff_t bytes); >> @@ -2482,6 +2484,8 @@ extern int vfs_stat(const char __user *, struct kstat *); >> extern int vfs_lstat(const char __user *, struct kstat *); >> extern int vfs_fstat(unsigned int, struct kstat *); >> extern int vfs_fstatat(int , const char __user *, struct kstat *, int); >> +extern int vfs_xstat(int, const char __user *, int, struct kstat *); >> +extern int vfs_xfstat(unsigned int, struct kstat *); >> >> extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, >> unsigned long arg); >> diff --git a/include/linux/stat.h b/include/linux/stat.h >> index 611c398..0ff561a 100644 >> --- a/include/linux/stat.h >> +++ b/include/linux/stat.h >> @@ -3,6 +3,7 @@ >> >> #ifdef __KERNEL__ >> >> +#include <linux/types.h> >> #include <asm/stat.h> >> >> #endif >> @@ -46,6 +47,117 @@ >> >> #endif >> >> +/* >> + * Query request/result mask >> + * >> + * Bits should be set in request_mask to request particular items when calling >> + * xstat() or fxstat(). >> + * >> + * The bits in st_mask may or may not be set upon return, in part depending on >> + * what was set in the mask argument: >> + * >> + * - if not available at all, the bit will be cleared before returning and the >> + * field will be cleared; otherwise, >> + * >> + * - if AT_FORCE_ATTR_SYNC is set, then the datum will be synchronised to the >> + * server and the field and bit will be set on return; otherwise, >> + * >> + * - if explicitly requested, the datum will be synchronised to a server or >> + * other medium if out of date before being returned, and the bit will be set >> + * on return; otherwise, >> + * >> + * - if not requested, but available in approximate form without any effort, it >> + * will be filled in anyway, and the bit will be set upon return (it might >> + * not be up to date, however, and no attempt will be made to synchronise the >> + * internal state first); otherwise, >> + * >> + * - the field and the bit will be cleared before returning. >> + * >> + * Items in XSTAT_BASIC_STATS may be marked unavailable on return, but they >> + * will have a value installed for compatibility purposes so that stat() and >> + * co. can be emulated in userspace. >> + */ >> +#define XSTAT_MODE 0x00000001U /* want/got st_mode */ >> +#define XSTAT_NLINK 0x00000002U /* want/got st_nlink */ >> +#define XSTAT_UID 0x00000004U /* want/got st_uid */ >> +#define XSTAT_GID 0x00000008U /* want/got st_gid */ >> +#define XSTAT_RDEV 0x00000010U /* want/got st_rdev */ >> +#define XSTAT_ATIME 0x00000020U /* want/got st_atime */ >> +#define XSTAT_MTIME 0x00000040U /* want/got st_mtime */ >> +#define XSTAT_CTIME 0x00000080U /* want/got st_ctime */ >> +#define XSTAT_INO 0x00000100U /* want/got st_ino */ >> +#define XSTAT_SIZE 0x00000200U /* want/got st_size */ >> +#define XSTAT_BLOCKS 0x00000400U /* want/got st_blocks */ >> +#define XSTAT_BASIC_STATS 0x000007ffU /* the stuff in the normal stat struct */ >> +#define XSTAT_IOC_FLAGS 0x00000800U /* want/got FS_IOC_GETFLAGS */ >> +#define XSTAT_BTIME 0x00001000U /* want/got st_btime */ >> +#define XSTAT_GEN 0x00002000U /* want/got st_gen */ >> +#define XSTAT_VERSION 0x00004000U /* want/got st_version */ >> +#define XSTAT_VOLUME_ID 0x00008000U /* want/got st_volume_id */ >> +#define XSTAT_ALL_STATS 0x0000ffffU /* all supported stats */ >> + >> +/* >> + * Extended stat structures >> + */ >> +struct xstat_dev { >> + uint32_t major, minor; >> +}; >> + >> +struct xstat_time { >> + int64_t tv_sec; >> + uint32_t tv_nsec; >> + uint32_t tv_granularity; /* time granularity (in nS) */ >> +}; >> + >> +struct xstat { >> + uint32_t st_mask; /* what results were written */ >> + uint32_t st_mode; /* file mode */ >> + uint32_t st_nlink; /* number of hard links */ >> + uint32_t st_uid; /* user ID of owner */ >> + uint32_t st_gid; /* group ID of owner */ >> + uint32_t st_information; /* information about the file */ >> + uint32_t st_ioc_flags; /* as FS_IOC_GETFLAGS */ >> + uint32_t st_blksize; /* optimal size for filesystem I/O */ >> + struct xstat_dev st_rdev; /* device ID of special file */ >> + struct xstat_dev st_dev; /* ID of device containing file */ >> + struct xstat_time st_atime; /* last access time */ >> + struct xstat_time st_btime; /* file creation time */ >> + struct xstat_time st_ctime; /* last attribute change time */ >> + struct xstat_time st_mtime; /* last data modification time */ >> + uint64_t st_ino; /* inode number */ >> + uint64_t st_size; /* file size */ >> + uint64_t st_blocks; /* number of 512-byte blocks allocated */ >> + uint64_t st_gen; /* inode generation number */ >> + uint64_t st_version; /* data version number */ >> + uint8_t st_volume_id[16]; /* volume identifier */ >> + uint64_t __spares[11]; /* spare space for future expansion */ >> +}; >> + >> +/* >> + * Flags to be found in st_information >> + * >> + * These give information about the features or the state of a file that might >> + * be of use to ordinary userspace programs such as GUIs or ls rather than >> + * specialised tools. >> + * >> + * Additional information may be found in st_ioc_flags and we try not to >> + * overlap with it. >> + */ >> +#define XSTAT_INFO_ENCRYPTED 0x00000001U /* File is encrypted */ >> +#define XSTAT_INFO_TEMPORARY 0x00000002U /* File is temporary (NTFS/CIFS) */ >> +#define XSTAT_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */ >> +#define XSTAT_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */ >> +#define XSTAT_INFO_REMOTE 0x00000010U /* File is remote */ >> +#define XSTAT_INFO_OFFLINE 0x00000020U /* File is offline (CIFS) */ >> +#define XSTAT_INFO_AUTOMOUNT 0x00000040U /* Dir is automount trigger */ >> +#define XSTAT_INFO_AUTODIR 0x00000080U /* Dir provides unlisted automounts */ >> +#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U /* File has non-system ownership details */ >> +#define XSTAT_INFO_HAS_ACL 0x00000200U /* File has an ACL of some sort */ >> +#define XSTAT_INFO_REPARSE_POINT 0x00000400U /* File is reparse point (NTFS/CIFS) */ >> +#define XSTAT_INFO_HIDDEN 0x00000800U /* File is marked hidden (DOS+) */ >> +#define XSTAT_INFO_SYSTEM 0x00001000U /* File is marked system (DOS+) */ >> +#define XSTAT_INFO_ARCHIVE 0x00002000U /* File is marked archive (DOS+) */ >> + >> #ifdef __KERNEL__ >> #define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO) >> #define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO) >> @@ -60,6 +172,12 @@ >> #include <linux/time.h> >> >> struct kstat { >> + u32 query_flags; /* operational flags */ >> +#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC) >> + u32 request_mask; /* what fields the user asked for */ >> + u32 result_mask; /* what fields the user got */ >> + u32 information; >> + u32 ioc_flags; /* inode flags (FS_IOC_GETFLAGS) */ >> u64 ino; >> dev_t dev; >> umode_t mode; >> @@ -67,14 +185,18 @@ struct kstat { >> uid_t uid; >> gid_t gid; >> dev_t rdev; >> + unsigned int tv_granularity; /* granularity of times (in nS) */ >> loff_t size; >> - struct timespec atime; >> + struct timespec atime; >> struct timespec mtime; >> struct timespec ctime; >> + struct timespec btime; /* file creation time */ >> unsigned long blksize; >> unsigned long long blocks; >> + u64 gen; /* inode generation */ >> + u64 version; /* data version */ >> + unsigned char volume_id[16]; /* volume identifier */ >> }; >> >> #endif >> - >> #endif >> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h >> index 3de3acb..ff9f8d9 100644 >> --- a/include/linux/syscalls.h >> +++ b/include/linux/syscalls.h >> @@ -45,6 +45,8 @@ struct shmid_ds; >> struct sockaddr; >> struct stat; >> struct stat64; >> +struct xstat_parameters; >> +struct xstat; >> struct statfs; >> struct statfs64; >> struct __sysctl_args; >> @@ -858,4 +860,9 @@ asmlinkage long sys_process_vm_writev(pid_t pid, >> unsigned long riovcnt, >> unsigned long flags); >> >> +asmlinkage long sys_xstat(int dfd, const char __user *path, unsigned flags, >> + unsigned mask, struct xstat __user *buffer); >> +asmlinkage long sys_fxstat(unsigned fd, unsigned flags, >> + unsigned mask, struct xstat __user *buffer); >> + >> #endif >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo(a)vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas

April 25, 2012

Re: vbscript: 'property' may be both keyword and identifier

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18045 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 25, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by Steve French

On Tue, Apr 24, 2012 at 4:29 PM, J. Bruce Fields <bfields(a)fieldses.org> wrote: > On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote: >> Add a pair of system calls to make extended file stats available, including >> file creation time, inode version and data version where available through the >> underlying filesystem. >> >> The idea was initially proposed as a set of xattrs that could be retrieved with >> getxattr(), but the general preferance proved to be for new syscalls with an >> extended stat structure. >> >> This has a number of uses: >> >> (1) Creation time: The SMB protocol carries the creation time, which could be >> exported by Samba, which will in turn help CIFS make use of FS-Cache as >> that can be used for coherency data. >> >> This is also specified in NFSv4 as a recommended attribute and could be >> exported by NFSD [Steve French]. >> >> (2) Lightweight stat: Ask for just those details of interest, and allow a >> netfs (such as NFS) to approximate anything not of interest, possibly >> without going to the server [Trond Myklebust, Ulrich Drepper]. >> >> (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its >> cached attributes are up to date [Trond Myklebust]. >> >> (4) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd >> Schubert]. >> >> (5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar]. >> >> Can also be used to modify fill_post_wcc() in NFSD which retrieves >> i_version directly, but has just called vfs_getattr(). It could get it >> from the kstat struct if it used vfs_xgetattr() instead. >> >> (6) BSD stat compatibility: Including more fields from the BSD stat such as >> creation time (st_btime) and inode generation number (st_gen) [Jeremy >> Allison, Bernd Schubert]. >> >> (7) Extra coherency data may be useful in making backups [Andreas Dilger]. >> >> (8) Allow the filesystem to indicate what it can/cannot provide: A filesystem >> can now say it doesn't support a standard stat feature if that isn't >> available, so if, for instance, inode numbers or UIDs don't exist... >> >> (9) Make the fields a consistent size on all arches and make them large. >> >> (10) Store a 16-byte volume ID in the superblock that can be returned in struct >> xstat [Steve French]. >> >> (11) Include granularity fields in the time data to indicate the granularity of >> each of the times (NFSv4 time_delta) [Steve French]. > > It looks like you're including this with *each* time? But surely > there's no filesystem with different granularity (say) for ctime than > for mtime. Also, nfsd will want only one time_delta, not one for each > time. > > Note also we need to document carefully what this means: I think it > should be the granularity that the filesystem is capable of > representing, but people are sometimes surprised to find out that the > actual time source is usually more coarse-grained than that. I also would prefer that we simply treat the time granularity as part of the superblock (mounted volume) ie returned on fstat rather than on every stat of the filesystem. For cifs mounts we could conceivably have different time granularity (1 or 2 second) on mounts to old servers rather than 100 nanoseconds. -- Thanks, Steve

April 24, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by J. Bruce Fields

On Thu, Apr 19, 2012 at 03:06:12PM +0100, David Howells wrote: > Add a pair of system calls to make extended file stats available, including > file creation time, inode version and data version where available through the > underlying filesystem. > > The idea was initially proposed as a set of xattrs that could be retrieved with > getxattr(), but the general preferance proved to be for new syscalls with an > extended stat structure. > > This has a number of uses: > > (1) Creation time: The SMB protocol carries the creation time, which could be > exported by Samba, which will in turn help CIFS make use of FS-Cache as > that can be used for coherency data. > > This is also specified in NFSv4 as a recommended attribute and could be > exported by NFSD [Steve French]. > > (2) Lightweight stat: Ask for just those details of interest, and allow a > netfs (such as NFS) to approximate anything not of interest, possibly > without going to the server [Trond Myklebust, Ulrich Drepper]. > > (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its > cached attributes are up to date [Trond Myklebust]. > > (4) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd > Schubert]. > > (5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar]. > > Can also be used to modify fill_post_wcc() in NFSD which retrieves > i_version directly, but has just called vfs_getattr(). It could get it > from the kstat struct if it used vfs_xgetattr() instead. > > (6) BSD stat compatibility: Including more fields from the BSD stat such as > creation time (st_btime) and inode generation number (st_gen) [Jeremy > Allison, Bernd Schubert]. > > (7) Extra coherency data may be useful in making backups [Andreas Dilger]. > > (8) Allow the filesystem to indicate what it can/cannot provide: A filesystem > can now say it doesn't support a standard stat feature if that isn't > available, so if, for instance, inode numbers or UIDs don't exist... > > (9) Make the fields a consistent size on all arches and make them large. > > (10) Store a 16-byte volume ID in the superblock that can be returned in struct > xstat [Steve French]. > > (11) Include granularity fields in the time data to indicate the granularity of > each of the times (NFSv4 time_delta) [Steve French]. It looks like you're including this with *each* time? But surely there's no filesystem with different granularity (say) for ctime than for mtime. Also, nfsd will want only one time_delta, not one for each time. Note also we need to document carefully what this means: I think it should be the granularity that the filesystem is capable of representing, but people are sometimes surprised to find out that the actual time source is usually more coarse-grained than that. --b. > > (12) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. > > (13) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer, > Michael Kerrisk]. > > (14) Spare space, request flags and information flags are provided for future > expansion. > > > The following structures are defined for the use of these new system calls: > > struct xstat_dev { > uint32_t major, minor; > }; > > struct xstat_time { > uint64_t tv_sec; > uint32_t tv_nsec; > uint32_t tv_granularity; > }; > > struct xstat { > uint32_t st_mask; > uint32_t st_mode; > uint32_t st_nlink; > uint32_t st_uid; > uint32_t st_gid; > uint32_t st_information; > uint32_t st_ioc_flags; > uint32_t st_blksize; > struct xstat_dev st_rdev; > struct xstat_dev st_dev; > struct xstat_time st_atime; > struct xstat_time st_btime; > struct xstat_time st_ctime; > struct xstat_time st_mtime; > uint64_t st_ino; > uint64_t st_size; > uint64_t st_blocks; > uint64_t st_gen; > uint64_t st_version; > uint8_t st_volume_id[16]; > uint64_t __spares[11]; > }; > > where st_information is local system information about the file, st_btime is > the file creation time, st_gen is the inode generation (i_generation), > st_data_version is the data version number (i_version), st_ioc_flags is the > flags from FS_IOC_GETFLAGS, st_volume_id is where the volume identified is > stored, st_result_mask is a bitmask indicating the data provided and __spares[] > are where as-yet undefined fields can be placed. > > The defined bits in request_mask and st_mask are: > > XSTAT_MODE Want/got st_mode > XSTAT_NLINK Want/got st_nlink > XSTAT_UID Want/got st_uid > XSTAT_GID Want/got st_gid > XSTAT_RDEV Want/got st_rdev > XSTAT_ATIME Want/got st_atime > XSTAT_MTIME Want/got st_mtime > XSTAT_CTIME Want/got st_ctime > XSTAT_INO Want/got st_ino > XSTAT_SIZE Want/got st_size > XSTAT_BLOCKS Want/got st_blocks > XSTAT_BASIC_STATS [The stuff in the normal stat struct] > XSTAT_IOC_FLAGS Want/got FS_IOC_GETFLAGS > XSTAT_BTIME Want/got st_btime > XSTAT_GEN Want/got st_gen > XSTAT_VERSION Want/got st_data_version > XSTAT_VOLUME_ID Want/got st_volume_id > XSTAT_ALL_STATS [All currently available stuff] > > The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra flags > that might be supplied by the filesystem. Note that Ext4 returns flags outside > of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS. Should > {EXT4,FS}_FL_USER_VISIBLE be extended to cover them? Or should the extra flags > be suppressed? > > The defined bits in the st_information field give local system data on a file, > how it is accessed, where it is and what it does: > > XSTAT_INFO_ENCRYPTED File is encrypted > XSTAT_INFO_TEMPORARY File is temporary (NTFS/CIFS/deleted) > XSTAT_INFO_FABRICATED File was made up by filesystem > XSTAT_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) > XSTAT_INFO_REMOTE File is remote > XSTAT_INFO_OFFLINE File is offline (CIFS) > XSTAT_INFO_AUTOMOUNT Dir is automount trigger > XSTAT_INFO_AUTODIR Dir provides unlisted automounts > XSTAT_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details > XSTAT_INFO_HAS_ACL File has an ACL of some sort > XSTAT_INFO_REPARSE_POINT File is reparse point (NTFS/CIFS) > XSTAT_INFO_HIDDEN File is marked hidden (DOS+) > XSTAT_INFO_SYSTEM File is marked system (DOS+) > XSTAT_INFO_ARCHIVE File is marked archive (DOS+) > > These are for the use of GUI tools that might want to mark files specially, > depending on what they are. I've tried not to provide overlap with > st_ioc_flags where something usable exists there. Should Hidden, System and > Archive flags be associated with ioc_flags, perhaps with ioc_flags extended to > 64-bits? > > > The system calls are: > > ssize_t ret = xstat(int dfd, > const char *filename, > unsigned int flags, > unsigned int mask, > struct xstat *buffer); > > ssize_t ret = fxstat(unsigned fd, > unsigned int flags, > unsigned int mask, > struct xstat *buffer); > > > The dfd, filename, flags and fd parameters indicate the file to query. There > is no equivalent of lstat() as that can be emulated with xstat() by passing > AT_SYMLINK_NOFOLLOW in flags. > > AT_FORCE_ATTR_SYNC can also be set in flags. This will require a network > filesystem to synchronise its attributes with the server. > > mask is a bitmask indicating the fields in struct xstat that are of interest to > the caller. The user should set this to XSTAT__BASIC_STATS to get the > basic set returned by stat(). > > Should there just be one xstat() syscall that does fxstat() if filename is NULL? > > The fields in struct xstat come in a number of classes: > > (0) st_dev, st_blksize, st_information. > > These are local data and are always available. > > (1) st_mode, st_nlinks, st_uid, st_gid, st_[amc]time, st_ino, st_size, > st_blocks. > > These will be returned whether the caller asks for them or not. The > corresponding bits in result_mask will be set to indicate their presence. > > If the caller didn't ask for them, then they may be approximated. For > example, NFS won't waste any time updating them from the server, unless as > a byproduct of updating something requested. > > If the values don't actually exist for the underlying object (such as UID > or GID on a DOS file), then the bit won't be set in the result_mask, even > if the caller asked for the value and the returned value will be a > fabrication. > > (2) st_rdev. > > As for class (1), but this won't be returned if the file is not a blockdev > or chardev. The bit will be cleared if the value is not returned. > > (3) File creation time (st_btime), inode generation (st_gen), data version > (st_version), volume_id (st_volume_id) and inode flags (st_ioc_flags). > > These will be returned if available whether the caller asked for them or > not. The corresponding bits in result_mask will be set or cleared as > appropriate to indicate their presence. > > If the caller didn't ask for them, then they may be approximated. For > example, NFS won't waste any time updating them from the server, unless > as a byproduct of updating something requested. > > At the moment, this will only work on x86_64 and i386 as it requires system > calls to be wired up. > > > ======= > TESTING > ======= > > The following test program can be used to test the xstat system call: > > /* Test the xstat() system call > * > * Copyright (C) 2010 Red Hat, Inc. All Rights Reserved. > * Written by David Howells (dhowells(a)redhat.com) > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public Licence > * as published by the Free Software Foundation; either version > * 2 of the Licence, or (at your option) any later version. > */ > > #define _GNU_SOURCE > #define _ATFILE_SOURCE > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <unistd.h> > #include <fcntl.h> > #include <time.h> > #include <sys/syscall.h> > #include <sys/stat.h> > #include <sys/types.h> > > #define AT_NO_AUTOMOUNT 0x800 > #define AT_FORCE_ATTR_SYNC 0x2000 > > #define XSTAT_MODE 0x00000001U > #define XSTAT_NLINK 0x00000002U > #define XSTAT_UID 0x00000004U > #define XSTAT_GID 0x00000008U > #define XSTAT_RDEV 0x00000010U > #define XSTAT_ATIME 0x00000020U > #define XSTAT_MTIME 0x00000040U > #define XSTAT_CTIME 0x00000080U > #define XSTAT_INO 0x00000100U > #define XSTAT_SIZE 0x00000200U > #define XSTAT_BLOCKS 0x00000400U > #define XSTAT_BASIC_STATS 0x000007ffU > #define XSTAT_BTIME 0x00000800U > #define XSTAT_GEN 0x00001000U > #define XSTAT_VERSION 0x00002000U > #define XSTAT_IOC_FLAGS 0x00004000U > #define XSTAT_VOLUME_ID 0x00008000U > #define XSTAT_ALL_STATS 0x0000ffffU > > struct xstat_dev { > uint32_t major; > uint32_t minor; > }; > > struct xstat_time { > uint64_t tv_sec; > uint32_t tv_nsec; > uint32_t tv_granularity; > }; > > struct xstat { > uint32_t st_mask; > uint32_t st_mode; > uint32_t st_nlink; > uint32_t st_uid; > uint32_t st_gid; > uint32_t st_information; > uint32_t st_ioc_flags; > uint32_t st_blksize; > struct xstat_dev st_rdev; > struct xstat_dev st_dev; > struct xstat_time st_atim; > struct xstat_time st_btim; > struct xstat_time st_ctim; > struct xstat_time st_mtim; > uint64_t st_ino; > uint64_t st_size; > uint64_t st_blksize; > uint64_t st_blocks; > uint64_t st_gen; > uint64_t st_version; > uint64_t st_volume_id[16]; > uint64_t st_spares[11]; > }; > > #define XSTAT_INFO_ENCRYPTED 0x00000001U > #define XSTAT_INFO_TEMPORARY 0x00000002U > #define XSTAT_INFO_FABRICATED 0x00000004U > #define XSTAT_INFO_KERNEL_API 0x00000008U > #define XSTAT_INFO_REMOTE 0x00000010U > #define XSTAT_INFO_OFFLINE 0x00000020U > #define XSTAT_INFO_AUTOMOUNT 0x00000040U > #define XSTAT_INFO_AUTODIR 0x00000080U > #define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U > #define XSTAT_INFO_HAS_ACL 0x00000200U > #define XSTAT_INFO_REPARSE_POINT 0x00000400U > #define XSTAT_INFO_HIDDEN 0x00000800U > #define XSTAT_INFO_SYSTEM 0x00001000U > #define XSTAT_INFO_ARCHIVE 0x00002000U > > #define __NR_xstat 312 > #define __NR_fxstat 313 > > static __attribute__((unused)) > ssize_t xstat(int dfd, const char *filename, unsigned flags, > unsigned int mask, struct xstat *buffer) > { > return syscall(__NR_xstat, dfd, filename, flags, mask, buffer); > } > > static __attribute__((unused)) > ssize_t fxstat(int fd, unsigned flags, > unsigned int mask, struct xstat *buffer) > { > return syscall(__NR_fxstat, fd, flags, mask, buffer); > } > > static void print_time(const char *field, const struct xstat_time *xstm) > { > struct tm tm; > time_t tim; > char buffer[100]; > int len; > > tim = xstm->tv_sec; > if (!localtime_r(&tim, &tm)) { > perror("localtime_r"); > exit(1); > } > len = strftime(buffer, 100, "%F %T", &tm); > if (len == 0) { > perror("strftime"); > exit(1); > } > printf("%s", field); > fwrite(buffer, 1, len, stdout); > printf(".%09u", xstm->tv_nsec); > len = strftime(buffer, 100, "%z", &tm); > if (len == 0) { > perror("strftime2"); > exit(1); > } > fwrite(buffer, 1, len, stdout); > printf("\n"); > } > > static void dump_xstat(struct xstat *xst) > { > char buffer[256], ft; > > printf("results=%x\n", xst->st_mask); > > printf(" "); > if (xst->st_mask & XSTAT_SIZE) > printf(" Size: %-15llu", (unsigned long long) xst->st_size); > if (xst->st_mask & XSTAT_BLOCKS) > printf(" Blocks: %-10llu", (unsigned long long) xst->st_blocks); > printf(" IO Block: %-6llu ", (unsigned long long) xst->st_blksize); > if (xst->st_mask & XSTAT_MODE) { > switch (xst->st_mode & S_IFMT) { > case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break; > case S_IFCHR: printf(" character special file\n"); ft = 'c'; break; > case S_IFDIR: printf(" directory\n"); ft = 'd'; break; > case S_IFBLK: printf(" block special file\n"); ft = 'b'; break; > case S_IFREG: printf(" regular file\n"); ft = '-'; break; > case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break; > case S_IFSOCK: printf(" socket\n"); ft = 's'; break; > default: > printf("unknown type (%o)\n", xst->st_mode & S_IFMT); > ft = '?'; > break; > } > } > > sprintf(buffer, "%02x:%02x", xst->st_dev.major, xst->st_dev.minor); > printf("Device: %-15s", buffer); > if (xst->st_mask & XSTAT_INO) > printf(" Inode: %-11llu", (unsigned long long) xst->st_ino); > if (xst->st_mask & XSTAT_SIZE) > printf(" Links: %-5u", xst->st_nlink); > if (xst->st_mask & XSTAT_RDEV) > printf(" Device type: %u,%u", > xst->st_rdev.major, xst->st_rdev.minor); > printf("\n"); > > if (xst->st_mask & XSTAT_MODE) > printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", > xst->st_mode & 07777, > ft, > xst->st_mode & S_IRUSR ? 'r' : '-', > xst->st_mode & S_IWUSR ? 'w' : '-', > xst->st_mode & S_IXUSR ? 'x' : '-', > xst->st_mode & S_IRGRP ? 'r' : '-', > xst->st_mode & S_IWGRP ? 'w' : '-', > xst->st_mode & S_IXGRP ? 'x' : '-', > xst->st_mode & S_IROTH ? 'r' : '-', > xst->st_mode & S_IWOTH ? 'w' : '-', > xst->st_mode & S_IXOTH ? 'x' : '-'); > if (xst->st_mask & XSTAT_UID) > printf("Uid: %d \n", xst->st_uid); > if (xst->st_mask & XSTAT_GID) > printf("Gid: %u\n", xst->st_gid); > > if (xst->st_mask & XSTAT_ATIME) > print_time("Access: ", &xst->st_atim); > if (xst->st_mask & XSTAT_MTIME) > print_time("Modify: ", &xst->st_mtim); > if (xst->st_mask & XSTAT_CTIME) > print_time("Change: ", &xst->st_ctim); > if (xst->st_mask & XSTAT_BTIME) > print_time("Create: ", &xst->st_btim); > > if (xst->st_mask & XSTAT_GEN) > printf("Inode version: %llxh\n", (unsigned long long) xst->st_gen); > if (xst->st_mask & XSTAT_VERSION) > printf("Data version: %llxh\n", (unsigned long long) xst->st_version); > > if (xst->st_mask & XSTAT_IOC_FLAGS) { > unsigned char bits; > int loop, byte; > > static char flag_representation[32 + 1] = > /* FS_IOC_GETFLAGS flags: */ > "????????" /* 31-24 0x00000000-ff000000 */ > "????ehTD" /* 23-16 0x00000000-00ff0000 */ > "tj?IE?XZ" /* 15- 8 0x00000000-0000ff00 */ > "AdaiScus" /* 7- 0 0x00000000-000000ff */ > ; > > printf("Inode flags: %08x (", xst->st_ioc_flags); > for (byte = 32 - 8; byte >= 0; byte -= 8) { > bits = xst->st_ioc_flags >> byte; > for (loop = 7; loop >= 0; loop--) { > int bit = byte + loop; > > if (bits & 0x80) > putchar(flag_representation[31 - bit]); > else > putchar('-'); > bits <<= 1; > } > if (byte) > putchar(' '); > } > printf(")\n"); > } > > if (xst->st_information) { > unsigned char bits; > int loop, byte; > > static char info_representation[32 + 1] = > /* XSTAT_INFO_ flags: */ > "????????" /* 31-24 0x00000000-ff000000 */ > "????????" /* 23-16 0x00000000-00ff0000 */ > "??ASHRan" /* 15- 8 0x00000000-0000ff00 */ > "dmorkfte" /* 7- 0 0x00000000-000000ff */ > ; > > printf("Information: %08x (", xst->st_information); > for (byte = 32 - 8; byte >= 0; byte -= 8) { > bits = xst->st_information >> byte; > for (loop = 7; loop >= 0; loop--) { > int bit = byte + loop; > > if (bits & 0x80) > putchar(info_representation[31 - bit]); > else > putchar('-'); > bits <<= 1; > } > if (byte) > putchar(' '); > } > printf(")\n"); > } > > if (xst->st_mask & XSTAT_VOLUME_ID) { > int loop; > printf("Volume ID: "); > for (loop = 0; loop < sizeof(xst->st_volume_id); loop++) { > printf("%02x", xst->st_volume_id[loop]); > if (loop == 7) > printf("-"); > } > printf("\n"); > } > } > > void dump_hex(unsigned long long *data, int from, int to) > { > unsigned offset, print_offset = 1, col = 0; > > from /= 8; > to = (to + 7) / 8; > > for (offset = from; offset < to; offset++) { > if (print_offset) { > printf("%04x: ", offset * 8); > print_offset = 0; > } > printf("%016llx", data[offset]); > col++; > if ((col & 3) == 0) { > printf("\n"); > print_offset = 1; > } else { > printf(" "); > } > } > > if (!print_offset) > printf("\n"); > } > > int main(int argc, char **argv) > { > struct xstat xst; > int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW; > > unsigned int mask = XSTAT_ALL_STATS; > > for (argv++; *argv; argv++) { > if (strcmp(*argv, "-F") == 0) { > atflag |= AT_FORCE_ATTR_SYNC; > continue; > } > if (strcmp(*argv, "-L") == 0) { > atflag &= ~AT_SYMLINK_NOFOLLOW; > continue; > } > if (strcmp(*argv, "-O") == 0) { > mask &= ~XSTAT_BASIC_STATS; > continue; > } > if (strcmp(*argv, "-A") == 0) { > atflag |= AT_NO_AUTOMOUNT; > continue; > } > if (strcmp(*argv, "-R") == 0) { > raw = 1; > continue; > } > > memset(&xst, 0xbf, sizeof(xst)); > ret = xstat(AT_FDCWD, *argv, atflag, mask, &xst); > printf("xstat(%s) = %d\n", *argv, ret); > if (ret < 0) { > perror(*argv); > exit(1); > } > > if (raw) > dump_hex((unsigned long long *)&xst, 0, sizeof(xst)); > > dump_xstat(&xst); > } > return 0; > } > > Just compile and run, passing it paths to the files you want to examine: > > [root(a)andromeda ~]# /tmp/xstat /proc/$$ > xstat(/proc/2074) = 160 > results=47ef > Size: 0 Blocks: 0 IO Block: 1024 directory > Device: 00:03 Inode: 9072 Links: 7 > Access: (0555/dr-xr-xr-x) Uid: 0 > Gid: 0 > Access: 2010-07-14 16:50:46.609336272+0100 > Modify: 2010-07-14 16:50:46.609336272+0100 > Change: 2010-07-14 16:50:46.609336272+0100 > Inode flags: 0000000100000000 (-------- -------- -------- -------S -------- -------- -------- --------) > [root(a)andromeda ~]# /tmp/xstat /afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm > xstat(/afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm) = 160 > results=77ef > Size: 5413882 Blocks: 0 IO Block: 4096 regular file > Device: 00:15 Inode: 2288 Links: 1 > Access: (0644/-rw-r--r--) Uid: 75338 > Gid: 0 > Access: 2008-11-05 19:47:22.000000000+0000 > Modify: 2008-11-05 19:47:22.000000000+0000 > Change: 2008-11-05 19:47:22.000000000+0000 > Inode version: 795h > Data version: 2h > Inode flags: 0000000800000000 (-------- -------- -------- ----r--- -------- -------- -------- --------) > > Signed-off-by: David Howells <dhowells(a)redhat.com> > --- > > arch/x86/syscalls/syscall_32.tbl | 2 > arch/x86/syscalls/syscall_64.tbl | 2 > fs/stat.c | 350 +++++++++++++++++++++++++++++++++++--- > include/linux/fcntl.h | 1 > include/linux/fs.h | 4 > include/linux/stat.h | 126 +++++++++++++- > include/linux/syscalls.h | 7 + > 7 files changed, 461 insertions(+), 31 deletions(-) > > diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl > index 29f9f05..980eb5a 100644 > --- a/arch/x86/syscalls/syscall_32.tbl > +++ b/arch/x86/syscalls/syscall_32.tbl > @@ -355,3 +355,5 @@ > 346 i386 setns sys_setns > 347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv > 348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev > +349 i386 xstat sys_xstat > +350 i386 fxstat sys_fxstat > diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl > index dd29a9e..7ae24bb 100644 > --- a/arch/x86/syscalls/syscall_64.tbl > +++ b/arch/x86/syscalls/syscall_64.tbl > @@ -318,6 +318,8 @@ > 309 common getcpu sys_getcpu > 310 64 process_vm_readv sys_process_vm_readv > 311 64 process_vm_writev sys_process_vm_writev > +312 common xstat sys_xstat > +313 common fxstat sys_fxstat > # > # x32-specific system call numbers start at 512 to avoid cache impact > # for native 64-bit operation. > diff --git a/fs/stat.c b/fs/stat.c > index c733dc5..af3ef33 100644 > --- a/fs/stat.c > +++ b/fs/stat.c > @@ -18,8 +18,20 @@ > #include <asm/uaccess.h> > #include <asm/unistd.h> > > +/** > + * generic_fillattr - Fill in the basic attributes from the inode struct > + * @inode: Inode to use as the source > + * @stat: Where to fill in the attributes > + * > + * Fill in the basic attributes in the kstat structure from data that's to be > + * found on the VFS inode structure. This is the default if no getattr inode > + * operation is supplied. > + */ > void generic_fillattr(struct inode *inode, struct kstat *stat) > { > + struct super_block *sb = inode->i_sb; > + u32 x; > + > stat->dev = inode->i_sb->s_dev; > stat->ino = inode->i_ino; > stat->mode = inode->i_mode; > @@ -27,17 +39,61 @@ void generic_fillattr(struct inode *inode, struct kstat *stat) > stat->uid = inode->i_uid; > stat->gid = inode->i_gid; > stat->rdev = inode->i_rdev; > - stat->size = i_size_read(inode); > - stat->atime = inode->i_atime; > stat->mtime = inode->i_mtime; > stat->ctime = inode->i_ctime; > - stat->blksize = (1 << inode->i_blkbits); > + stat->size = i_size_read(inode); > stat->blocks = inode->i_blocks; > -} > + stat->blksize = (1 << inode->i_blkbits); > > + stat->result_mask |= XSTAT_BASIC_STATS & ~XSTAT_RDEV; > + if (IS_NOATIME(inode)) > + stat->result_mask &= ~XSTAT_ATIME; > + else > + stat->atime = inode->i_atime; > + > + if (S_ISREG(stat->mode) && stat->nlink == 0) > + stat->information |= XSTAT_INFO_TEMPORARY; > + if (IS_AUTOMOUNT(inode)) > + stat->information |= XSTAT_INFO_AUTOMOUNT; > + if (IS_POSIXACL(inode)) > + stat->information |= XSTAT_INFO_HAS_ACL; > + > + /* if unset, assume 1s granularity */ > + stat->tv_granularity = sb->s_time_gran ?: 1000000000U; > + > + if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode))) > + stat->result_mask |= XSTAT_RDEV; > + > + x = ((u32*)&stat->volume_id)[0] = ((u32*)&sb->s_volume_id)[0]; > + x |= ((u32*)&stat->volume_id)[1] = ((u32*)&sb->s_volume_id)[1]; > + x |= ((u32*)&stat->volume_id)[2] = ((u32*)&sb->s_volume_id)[2]; > + x |= ((u32*)&stat->volume_id)[3] = ((u32*)&sb->s_volume_id)[3]; > + if (x) > + stat->result_mask |= XSTAT_VOLUME_ID; > +} > EXPORT_SYMBOL(generic_fillattr); > > -int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) > +/** > + * vfs_xgetattr - Get the basic and extra attributes of a file > + * @mnt: The mountpoint to which the dentry belongs > + * @dentry: The file of interest > + * @stat: Where to return the statistics > + * > + * Ask the filesystem for a file's attributes. The caller must have preset > + * stat->request_mask and stat->query_flags to indicate what they want. > + * > + * If the file is remote, the filesystem can be forced to update the attributes > + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags. > + * > + * Bits must have been set in stat->request_mask to indicate which attributes > + * the caller wants retrieving. Any such attribute not requested may be > + * returned anyway, but the value may be approximate, and, if remote, may not > + * have been synchronised with the server. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry, > + struct kstat *stat) > { > struct inode *inode = dentry->d_inode; > int retval; > @@ -46,64 +102,184 @@ int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) > if (retval) > return retval; > > + stat->result_mask = 0; > + stat->information = 0; > + stat->ioc_flags = 0; > if (inode->i_op->getattr) > return inode->i_op->getattr(mnt, dentry, stat); > > generic_fillattr(inode, stat); > return 0; > } > +EXPORT_SYMBOL(vfs_xgetattr); > > +/** > + * vfs_getattr - Get the basic attributes of a file > + * @mnt: The mountpoint to which the dentry belongs > + * @dentry: The file of interest > + * @stat: Where to return the statistics > + * > + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't > + * forced to update its files from the backing store. Only the basic set of > + * attributes will be retrieved; anyone wanting more must use vfs_getxattr(), > + * as must anyone who wants to force attributes to be sync'd with the server. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) > +{ > + stat->query_flags = 0; > + stat->request_mask = XSTAT_BASIC_STATS; > + return vfs_xgetattr(mnt, dentry, stat); > +} > EXPORT_SYMBOL(vfs_getattr); > > -int vfs_fstat(unsigned int fd, struct kstat *stat) > +/** > + * vfs_fxstat - Get basic and extra attributes by file descriptor > + * @fd: The file descriptor refering to the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xgetattr(). The main difference is > + * that it uses a file descriptor to determine the file location. > + * > + * The caller must have preset stat->query_flags and stat->request_mask as for > + * vfs_xgetattr(). > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_fxstat(unsigned int fd, struct kstat *stat) > { > struct file *f = fget(fd); > int error = -EBADF; > > + if (stat->query_flags & ~KSTAT_QUERY_FLAGS) > + return -EINVAL; > if (f) { > - error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat); > + error = vfs_xgetattr(f->f_path.mnt, f->f_path.dentry, stat); > fput(f); > } > return error; > } > +EXPORT_SYMBOL(vfs_fxstat); > + > +/** > + * vfs_fstat - Get basic attributes by file descriptor > + * @fd: The file descriptor refering to the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_getattr(). The main difference is > + * that it uses a file descriptor to determine the file location. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_fstat(unsigned int fd, struct kstat *stat) > +{ > + stat->query_flags = 0; > + stat->request_mask = XSTAT_BASIC_STATS; > + return vfs_fxstat(fd, stat); > +} > EXPORT_SYMBOL(vfs_fstat); > > -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, > - int flag) > +/** > + * vfs_xstat - Get basic and extra attributes by filename > + * @dfd: A file descriptor representing the base dir for a relative filename > + * @filename: The name of the file of interest > + * @flags: Flags to control the query > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xgetattr(). The main difference is > + * that it uses a filename and base directory to determine the file location. > + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a > + * symlink at the given name from being referenced. > + * > + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The > + * flags are also used to load up stat->query_flags. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_xstat(int dfd, const char __user *filename, int flags, > + struct kstat *stat) > { > struct path path; > - int error = -EINVAL; > - int lookup_flags = 0; > + int error, lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT; > > - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | > - AT_EMPTY_PATH)) != 0) > - goto out; > + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | > + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0) > + return -EINVAL; > > - if (!(flag & AT_SYMLINK_NOFOLLOW)) > - lookup_flags |= LOOKUP_FOLLOW; > - if (flag & AT_EMPTY_PATH) > + if (flags & AT_SYMLINK_NOFOLLOW) > + lookup_flags &= ~LOOKUP_FOLLOW; > + if (flags & AT_NO_AUTOMOUNT) > + lookup_flags &= ~LOOKUP_AUTOMOUNT; > + if (flags & AT_EMPTY_PATH) > lookup_flags |= LOOKUP_EMPTY; > > + stat->query_flags = flags & KSTAT_QUERY_FLAGS; > error = user_path_at(dfd, filename, lookup_flags, &path); > - if (error) > - goto out; > - > - error = vfs_getattr(path.mnt, path.dentry, stat); > - path_put(&path); > -out: > + if (!error) { > + error = vfs_xgetattr(path.mnt, path.dentry, stat); > + path_put(&path); > + } > return error; > } > +EXPORT_SYMBOL(vfs_xstat); > + > +/** > + * vfs_fstatat - Get basic attributes by filename > + * @dfd: A file descriptor representing the base dir for a relative filename > + * @filename: The name of the file of interest > + * @flags: Flags to control the query > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xstat(). The difference is that it > + * preselects basic stats only. The flags are used to load up > + * stat->query_flags in addition to indicating symlink handling during path > + * resolution. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, > + int flags) > +{ > + stat->request_mask = XSTAT_BASIC_STATS; > + return vfs_xstat(dfd, filename, flags, stat); > +} > EXPORT_SYMBOL(vfs_fstatat); > > -int vfs_stat(const char __user *name, struct kstat *stat) > +/** > + * vfs_stat - Get basic attributes by filename > + * @filename: The name of the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xstat(). The difference is that it > + * preselects basic stats only, terminal symlinks are followed regardless and a > + * remote filesystem can't be forced to query the server. If such is desired, > + * vfs_xstat() should be used instead. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > +int vfs_stat(const char __user *filename, struct kstat *stat) > { > - return vfs_fstatat(AT_FDCWD, name, stat, 0); > + stat->request_mask = XSTAT_BASIC_STATS; > + return vfs_xstat(AT_FDCWD, filename, 0, stat); > } > EXPORT_SYMBOL(vfs_stat); > > +/** > + * vfs_stat - Get basic attributes by filename, without following terminal symlink > + * @filename: The name of the file of interest > + * @stat: The result structure to fill in. > + * > + * This function is a wrapper around vfs_xstat(). The difference is that it > + * preselects basic stats only, terminal symlinks are note followed regardless > + * and a remote filesystem can't be forced to query the server. If such is > + * desired, vfs_xstat() should be used instead. > + * > + * 0 will be returned on success, and a -ve error code if unsuccessful. > + */ > int vfs_lstat(const char __user *name, struct kstat *stat) > { > - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW); > + return vfs_xstat(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat); > } > EXPORT_SYMBOL(vfs_lstat); > > @@ -118,7 +294,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta > { > static int warncount = 5; > struct __old_kernel_stat tmp; > - > + > if (warncount > 0) { > warncount--; > printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n", > @@ -143,7 +319,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta > #if BITS_PER_LONG == 32 > if (stat->size > MAX_NON_LFS) > return -EOVERFLOW; > -#endif > +#endif > tmp.st_size = stat->size; > tmp.st_atime = stat->atime.tv_sec; > tmp.st_mtime = stat->mtime.tv_sec; > @@ -225,7 +401,7 @@ static int cp_new_stat(struct kstat *stat, struct stat __user *statbuf) > #if BITS_PER_LONG == 32 > if (stat->size > MAX_NON_LFS) > return -EOVERFLOW; > -#endif > +#endif > tmp.st_size = stat->size; > tmp.st_atime = stat->atime.tv_sec; > tmp.st_mtime = stat->mtime.tv_sec; > @@ -412,6 +588,122 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename, > } > #endif /* __ARCH_WANT_STAT64 */ > > +/* > + * Get the xstat parameters if supplied > + */ > +static int xstat_get_params(unsigned int mask, struct xstat __user *buffer, > + struct kstat *stat) > +{ > + memset(stat, 0xde, sizeof(*stat)); // DEBUGGING > + > + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer))) > + return -EFAULT; > + > + stat->request_mask = mask & XSTAT_ALL_STATS; > + stat->result_mask = 0; > + return 0; > +} > + > +/* > + * Set the xstat results. > + * > + * If the buffer size was 0, we just return the size of the buffer needed to > + * return the full result. > + * > + * If bufsize indicates a buffer of insufficient size to hold the full result, > + * we return -E2BIG. > + * > + * Otherwise we copy the extended stats to userspace and return the amount of > + * data written into the buffer (or -EFAULT). > + */ > +static long xstat_set_result(struct kstat *stat, struct xstat __user *buffer) > +{ > + u32 mask = stat->result_mask, gran = stat->tv_granularity; > + > +#define __put_timestamp(kts, uts) ( \ > + __put_user(kts.tv_sec, uts.tv_sec ) || \ > + __put_user(kts.tv_nsec, uts.tv_nsec ) || \ > + __put_user(gran, uts.tv_granularity )) > + > + /* clear out anything we're not returning */ > + if (!(mask & XSTAT_IOC_FLAGS)) > + stat->ioc_flags = 0; > + if (!(mask & XSTAT_BTIME)) > + memset(&stat->btime, 0, sizeof(stat->btime)); > + if (!(mask & XSTAT_GEN)) > + stat->gen = 0; > + if (!(mask & XSTAT_VERSION)) > + stat->version = 0; > + if (!(mask & XSTAT_VOLUME_ID)) > + memset(&stat->volume_id, 0, sizeof(stat->volume_id)); > + > + /* transfer the results */ > + if (__put_user(mask, &buffer->st_mask ) || > + __put_user(stat->mode, &buffer->st_mode ) || > + __put_user(stat->nlink, &buffer->st_nlink ) || > + __put_user(stat->uid, &buffer->st_uid ) || > + __put_user(stat->gid, &buffer->st_gid ) || > + __put_user(stat->information, &buffer->st_information ) || > + __put_user(stat->ioc_flags, &buffer->st_ioc_flags ) || > + __put_user(stat->blksize, &buffer->st_blksize ) || > + __put_user(MAJOR(stat->rdev), &buffer->st_rdev.major ) || > + __put_user(MINOR(stat->rdev), &buffer->st_rdev.minor ) || > + __put_user(MAJOR(stat->dev), &buffer->st_dev.major ) || > + __put_user(MINOR(stat->dev), &buffer->st_dev.minor ) || > + __put_timestamp(stat->atime, &buffer->st_atime ) || > + __put_timestamp(stat->btime, &buffer->st_btime ) || > + __put_timestamp(stat->ctime, &buffer->st_ctime ) || > + __put_timestamp(stat->mtime, &buffer->st_mtime ) || > + __put_user(stat->ino, &buffer->st_ino ) || > + __put_user(stat->size, &buffer->st_size ) || > + __put_user(stat->blocks, &buffer->st_blocks ) || > + __put_user(stat->gen, &buffer->st_gen ) || > + __put_user(stat->version, &buffer->st_version ) || > + __copy_to_user(&buffer->st_volume_id, &stat->volume_id, > + sizeof(buffer->st_volume_id) ) || > + __clear_user(&buffer->__spares, sizeof(buffer->__spares))) > + return -EFAULT; > + return 0; > +} > + > +/* > + * System call to get extended stats by path > + */ > +SYSCALL_DEFINE5(xstat, > + int, dfd, const char __user *, filename, unsigned, flags, > + unsigned int, mask, struct xstat __user *, buffer) > +{ > + struct kstat stat; > + int error; > + > + error = xstat_get_params(mask, buffer, &stat); > + if (error != 0) > + return error; > + error = vfs_xstat(dfd, filename, flags, &stat); > + if (error) > + return error; > + return xstat_set_result(&stat, buffer); > +} > + > +/* > + * System call to get extended stats by file descriptor > + */ > +SYSCALL_DEFINE4(fxstat, unsigned int, fd, unsigned int, flags, > + unsigned int, mask, struct xstat __user *, buffer) > +{ > + struct kstat stat; > + int error; > + > + error = xstat_get_params(mask, buffer, &stat); > + if (error < 0) > + return error; > + stat.query_flags = flags; > + error = vfs_fxstat(fd, &stat); > + if (error) > + return error; > + return xstat_set_result(&stat, buffer); > +} > + > /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */ > void __inode_add_bytes(struct inode *inode, loff_t bytes) > { > diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h > index f550f89..faa9e5d 100644 > --- a/include/linux/fcntl.h > +++ b/include/linux/fcntl.h > @@ -47,6 +47,7 @@ > #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ > #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */ > #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ > +#define AT_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ > > #ifdef __KERNEL__ > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 8de6755..ec6c62e 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -1467,6 +1467,7 @@ struct super_block { > > char s_id[32]; /* Informational name */ > u8 s_uuid[16]; /* UUID */ > + unsigned char s_volume_id[16]; /* Volume identifier */ > > void *s_fs_info; /* Filesystem private info */ > unsigned int s_max_links; > @@ -2470,6 +2471,7 @@ extern const struct inode_operations page_symlink_inode_operations; > extern int generic_readlink(struct dentry *, char __user *, int); > extern void generic_fillattr(struct inode *, struct kstat *); > extern int vfs_getattr(struct vfsmount *, struct dentry *, struct kstat *); > +extern int vfs_xgetattr(struct vfsmount *, struct dentry *, struct kstat *); > void __inode_add_bytes(struct inode *inode, loff_t bytes); > void inode_add_bytes(struct inode *inode, loff_t bytes); > void inode_sub_bytes(struct inode *inode, loff_t bytes); > @@ -2482,6 +2484,8 @@ extern int vfs_stat(const char __user *, struct kstat *); > extern int vfs_lstat(const char __user *, struct kstat *); > extern int vfs_fstat(unsigned int, struct kstat *); > extern int vfs_fstatat(int , const char __user *, struct kstat *, int); > +extern int vfs_xstat(int, const char __user *, int, struct kstat *); > +extern int vfs_xfstat(unsigned int, struct kstat *); > > extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, > unsigned long arg); > diff --git a/include/linux/stat.h b/include/linux/stat.h > index 611c398..0ff561a 100644 > --- a/include/linux/stat.h > +++ b/include/linux/stat.h > @@ -3,6 +3,7 @@ > > #ifdef __KERNEL__ > > +#include <linux/types.h> > #include <asm/stat.h> > > #endif > @@ -46,6 +47,117 @@ > > #endif > > +/* > + * Query request/result mask > + * > + * Bits should be set in request_mask to request particular items when calling > + * xstat() or fxstat(). > + * > + * The bits in st_mask may or may not be set upon return, in part depending on > + * what was set in the mask argument: > + * > + * - if not available at all, the bit will be cleared before returning and the > + * field will be cleared; otherwise, > + * > + * - if AT_FORCE_ATTR_SYNC is set, then the datum will be synchronised to the > + * server and the field and bit will be set on return; otherwise, > + * > + * - if explicitly requested, the datum will be synchronised to a server or > + * other medium if out of date before being returned, and the bit will be set > + * on return; otherwise, > + * > + * - if not requested, but available in approximate form without any effort, it > + * will be filled in anyway, and the bit will be set upon return (it might > + * not be up to date, however, and no attempt will be made to synchronise the > + * internal state first); otherwise, > + * > + * - the field and the bit will be cleared before returning. > + * > + * Items in XSTAT_BASIC_STATS may be marked unavailable on return, but they > + * will have a value installed for compatibility purposes so that stat() and > + * co. can be emulated in userspace. > + */ > +#define XSTAT_MODE 0x00000001U /* want/got st_mode */ > +#define XSTAT_NLINK 0x00000002U /* want/got st_nlink */ > +#define XSTAT_UID 0x00000004U /* want/got st_uid */ > +#define XSTAT_GID 0x00000008U /* want/got st_gid */ > +#define XSTAT_RDEV 0x00000010U /* want/got st_rdev */ > +#define XSTAT_ATIME 0x00000020U /* want/got st_atime */ > +#define XSTAT_MTIME 0x00000040U /* want/got st_mtime */ > +#define XSTAT_CTIME 0x00000080U /* want/got st_ctime */ > +#define XSTAT_INO 0x00000100U /* want/got st_ino */ > +#define XSTAT_SIZE 0x00000200U /* want/got st_size */ > +#define XSTAT_BLOCKS 0x00000400U /* want/got st_blocks */ > +#define XSTAT_BASIC_STATS 0x000007ffU /* the stuff in the normal stat struct */ > +#define XSTAT_IOC_FLAGS 0x00000800U /* want/got FS_IOC_GETFLAGS */ > +#define XSTAT_BTIME 0x00001000U /* want/got st_btime */ > +#define XSTAT_GEN 0x00002000U /* want/got st_gen */ > +#define XSTAT_VERSION 0x00004000U /* want/got st_version */ > +#define XSTAT_VOLUME_ID 0x00008000U /* want/got st_volume_id */ > +#define XSTAT_ALL_STATS 0x0000ffffU /* all supported stats */ > + > +/* > + * Extended stat structures > + */ > +struct xstat_dev { > + uint32_t major, minor; > +}; > + > +struct xstat_time { > + int64_t tv_sec; > + uint32_t tv_nsec; > + uint32_t tv_granularity; /* time granularity (in nS) */ > +}; > + > +struct xstat { > + uint32_t st_mask; /* what results were written */ > + uint32_t st_mode; /* file mode */ > + uint32_t st_nlink; /* number of hard links */ > + uint32_t st_uid; /* user ID of owner */ > + uint32_t st_gid; /* group ID of owner */ > + uint32_t st_information; /* information about the file */ > + uint32_t st_ioc_flags; /* as FS_IOC_GETFLAGS */ > + uint32_t st_blksize; /* optimal size for filesystem I/O */ > + struct xstat_dev st_rdev; /* device ID of special file */ > + struct xstat_dev st_dev; /* ID of device containing file */ > + struct xstat_time st_atime; /* last access time */ > + struct xstat_time st_btime; /* file creation time */ > + struct xstat_time st_ctime; /* last attribute change time */ > + struct xstat_time st_mtime; /* last data modification time */ > + uint64_t st_ino; /* inode number */ > + uint64_t st_size; /* file size */ > + uint64_t st_blocks; /* number of 512-byte blocks allocated */ > + uint64_t st_gen; /* inode generation number */ > + uint64_t st_version; /* data version number */ > + uint8_t st_volume_id[16]; /* volume identifier */ > + uint64_t __spares[11]; /* spare space for future expansion */ > +}; > + > +/* > + * Flags to be found in st_information > + * > + * These give information about the features or the state of a file that might > + * be of use to ordinary userspace programs such as GUIs or ls rather than > + * specialised tools. > + * > + * Additional information may be found in st_ioc_flags and we try not to > + * overlap with it. > + */ > +#define XSTAT_INFO_ENCRYPTED 0x00000001U /* File is encrypted */ > +#define XSTAT_INFO_TEMPORARY 0x00000002U /* File is temporary (NTFS/CIFS) */ > +#define XSTAT_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */ > +#define XSTAT_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */ > +#define XSTAT_INFO_REMOTE 0x00000010U /* File is remote */ > +#define XSTAT_INFO_OFFLINE 0x00000020U /* File is offline (CIFS) */ > +#define XSTAT_INFO_AUTOMOUNT 0x00000040U /* Dir is automount trigger */ > +#define XSTAT_INFO_AUTODIR 0x00000080U /* Dir provides unlisted automounts */ > +#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U /* File has non-system ownership details */ > +#define XSTAT_INFO_HAS_ACL 0x00000200U /* File has an ACL of some sort */ > +#define XSTAT_INFO_REPARSE_POINT 0x00000400U /* File is reparse point (NTFS/CIFS) */ > +#define XSTAT_INFO_HIDDEN 0x00000800U /* File is marked hidden (DOS+) */ > +#define XSTAT_INFO_SYSTEM 0x00001000U /* File is marked system (DOS+) */ > +#define XSTAT_INFO_ARCHIVE 0x00002000U /* File is marked archive (DOS+) */ > + > #ifdef __KERNEL__ > #define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO) > #define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO) > @@ -60,6 +172,12 @@ > #include <linux/time.h> > > struct kstat { > + u32 query_flags; /* operational flags */ > +#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC) > + u32 request_mask; /* what fields the user asked for */ > + u32 result_mask; /* what fields the user got */ > + u32 information; > + u32 ioc_flags; /* inode flags (FS_IOC_GETFLAGS) */ > u64 ino; > dev_t dev; > umode_t mode; > @@ -67,14 +185,18 @@ struct kstat { > uid_t uid; > gid_t gid; > dev_t rdev; > + unsigned int tv_granularity; /* granularity of times (in nS) */ > loff_t size; > - struct timespec atime; > + struct timespec atime; > struct timespec mtime; > struct timespec ctime; > + struct timespec btime; /* file creation time */ > unsigned long blksize; > unsigned long long blocks; > + u64 gen; /* inode generation */ > + u64 version; /* data version */ > + unsigned char volume_id[16]; /* volume identifier */ > }; > > #endif > - > #endif > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index 3de3acb..ff9f8d9 100644 > --- a/include/linux/syscalls.h > +++ b/include/linux/syscalls.h > @@ -45,6 +45,8 @@ struct shmid_ds; > struct sockaddr; > struct stat; > struct stat64; > +struct xstat_parameters; > +struct xstat; > struct statfs; > struct statfs64; > struct __sysctl_args; > @@ -858,4 +860,9 @@ asmlinkage long sys_process_vm_writev(pid_t pid, > unsigned long riovcnt, > unsigned long flags); > > +asmlinkage long sys_xstat(int dfd, const char __user *path, unsigned flags, > + unsigned mask, struct xstat __user *buffer); > +asmlinkage long sys_fxstat(unsigned fd, unsigned flags, > + unsigned mask, struct xstat __user *buffer); > + > #endif > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

April 24, 2012

Re: [PATCH 1/3] server: Revise completion behavior to allow completions for cancelled sockets (try 2).

by Erich E. Hoover

On Tue, Apr 24, 2012 at 11:08 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Erich E. Hoover" <ehoover(a)mines.edu> writes: > > ... > > This patch changes how the close socket operation works so that if > > an async operation is registered then closing the handle will be > > deferred until the async operation has completed. > > I would find it very suprising if this were how it's supposed to work, > particularly since multiple handles can of course be opened to the same > socket. You'll need very convincing tests for this... The issue is that the way the async callback works in ws2_32 it uses add_fd_completion() to create completions. Since that routine uses the socket handle, the specific handle used for the async operation needs to remain valid until after the async has completed. If that handle doesn't remain valid then the completion cannot be added. So, this code keeps that handle valid until the async is complete so that WS2_async_accept has a valid handle to work with. Erich Hoover ehoover(a)mines.edu

April 24, 2012

Re: [2/5] gdi32: Introduce a list of font file/data.

by Alexandre Julliard

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > On 2012-04-24 13:01:04 +0200, Alexandre Julliard wrote: >> Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: >> >> >> You can't compare files this way, different paths can point to the same >> >> file. >> > >> > This function finds font path, not file. So find_font_path would be >> > more appropriate name. >> >> What's the point of doing this if it doesn't catch identical files? > > I thought it could be used to implement RemoveFontResourceEx. That's precisely the sort of thing where you need a proper file identity comparison and not just a path string check. -- Alexandre Julliard julliard(a)winehq.org

April 24, 2012

Re: [PATCH 1/3] server: Revise completion behavior to allow completions for cancelled sockets (try 2).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > Real Name: > Erich Hoover > > Description: > This patch changes how the close socket operation works so that if > an async operation is registered then closing the handle will be > deferred until the async operation has completed. I would find it very suprising if this were how it's supposed to work, particularly since multiple handles can of course be opened to the same socket. You'll need very convincing tests for this... -- Alexandre Julliard julliard(a)winehq.org

April 24, 2012

Re: [2/5] gdi32: Introduce a list of font file/data.

by Kusanagi Kouichi

On 2012-04-24 13:01:04 +0200, Alexandre Julliard wrote: > Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > > >> You can't compare files this way, different paths can point to the same > >> file. > > > > This function finds font path, not file. So find_font_path would be > > more appropriate name. > > What's the point of doing this if it doesn't catch identical files? I thought it could be used to implement RemoveFontResourceEx. > -- > Alexandre Julliard > julliard(a)winehq.org

April 24, 2012

Re: [2/5] gdi32: Introduce a list of font file/data.

by Alexandre Julliard

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: >> You can't compare files this way, different paths can point to the same >> file. > > This function finds font path, not file. So find_font_path would be > more appropriate name. What's the point of doing this if it doesn't catch identical files? -- Alexandre Julliard julliard(a)winehq.org

April 24, 2012

Re: gdi32: Add support for emulating bold faces of bitmap fonts.

by Dmitry Timoshkov

Hello, Any feedback on this patch? -- Dmitry.

April 24, 2012

Re: winex11.drv: Windows always generates VK_DECIMAL for Del/. on a keypad.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Windows always generates VK_DECIMAL for Del/. on a keypad while some > > X11 keyboard layouts generate XK_KP_Separator instead of XK_KP_Decimal > > in order to produce a locale dependent numeric separator. > > > > X11 handles XK_KP_Separator same way as XK_KP_Decimal for all tested > > keyboard layouts, so passing XK_KP_Separator instead of XK_KP_Decimal > > to XKeysymToKeycode doesn't break things. Pressing Del/. with NumLock > > turned on still correctly generates '.' or ',' depending on keyboard > > layout and matches what Windows does. > > > > This patch fixes an application which uses VK_DECIMAL as a sign to break > > the input string and insert a separator while entering a currency/price. > > Is there anything else I could provide in helping to get this patch accepted? Any feedback on this? -- Dmitry.

April 24, 2012

Re: [3/5] mapi32: Convert sendmail_extended_mapi to Unicode

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > + > +/* Macro to test for validity before freeing a pointer */ > +#define mapi_heap_free(_ptr) if (_ptr) { HeapFree(GetProcessHeap(), 0, (_ptr)); } You don't need that. -- Alexandre Julliard julliard(a)winehq.org

April 24, 2012

GSOC 2012 has started

by Austin English

Howdy, Google Summer of Code 2012 has started, and we have 5 students this year: Józef Kucia - Implement missing functions in D3DX9, mentored by Stefan Dösinger - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/jos/58002 Lucas Fialho Zawacki, mentored by Joystick configuration and testing applet Marcus Meissner - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/lfzawacki/3… Magdalena Nowak - Control Panel, mentored by Owen Rudge - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/magdalena/1… Marek K Chmiel - Encryption – digital signature security, mentored by Juan Lang - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/mkchmiel/16… Qian Hong - GSoC project: Improve CJK font support, mentored by Aric Stewart - https://google-melange.appspot.com/gsoc/project/google/gsoc2012/fracting/11… Good luck everyone! -- -Austin

April 24, 2012

Re: Mono packaging status

by Scott Ritchie

On 4/23/12 1:45 AM, Jacek Caban wrote: > On 4/20/12 11:29 PM, Scott Ritchie wrote: >> On 4/19/12 1:54 AM, Jacek Caban wrote: >>> Hi Vincent, >>> >>> On 04/19/12 00:12, Vincent Povirk wrote: >>>> If for some reason you want to try it, the current version is at >>>> https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. >>>> I think I will need a new home for the binaries, because github only >>>> gives me enough space for about 5 of them. So, uh, don't count on that >>>> URL sticking around. >>> >>> The right place for this is probably SourceForge, like all our other >>> downloads. That's a detail to be handler during the final release >>> through. >>> >>> Cheers, >>> Jacek >>> >>> >> >> Sourceforge only gives us limited space that you can get through via a >> simple web URL. If we need Wine to automatically download this the way >> it does Gecko, then doing a normal "release" via sourceforge might not >> be enough (since Wine can't click through the page). This is why we >> were using things like the budgetdedicated hosting service (which is >> still available) in years past. > > I'm not sure what limited space you mean. We already have Wine Gecko on > SourceForge and a redirecting script on source.winehq.org, which is used > for automated downloads. AFAIK this way we don't have any limitations > and, as far as Wine packages are concerned, we don't depend on any > specific external mirror provider. > Perhaps I am misremembering bandwidth limitations as space ones, but I do recall that hosting the Ubuntu packages there simply did not work once we had more than a few thousand users long ago. Depending on how frequent a download mono is, we may run into the same issue (with a similar solution: most Ubuntu users don't ever hit the sourceforge gecko download because they get gecko from an automatically installed package that comes with the Wine package) Thanks, Scott Ritchie

April 24, 2012

Re: gdiplus: Use symbolic name of the font style.

by Nikolay Sivov

On 4/23/2012 17:31, Dmitry Timoshkov wrote: > --- > dlls/gdiplus/font.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 169e28f..8157b0a 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -767,7 +767,7 @@ GpStatus WINGDIPAPI GdipGetLineSpacing(GDIPCONST GpFontFamily *family, > static INT CALLBACK font_has_style_proc(const LOGFONTW *elf, > const TEXTMETRICW *ntm, DWORD type, LPARAM lParam) > { > - INT fontstyle=0; > + INT fontstyle = FontStyleRegular; > > if (!ntm) return 1; > Maybe it's better to make it 'enum FontStyle' after all.

April 23, 2012

Re: [2/2] gdi32: Enumerated font size should not be too large.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > Perhaps the original commit was added to work around this issue? No, it was added for a not related reason. > Note, you'll probably have to retrieve the metrics at the design size (2048) > in order to get accurate values for these members. Simply up-scaling the values > obtained at 100 ppem will lead to rounding errors. As you say, tests are needed. Yeah, the tests are needed. For now I just wanted to make gdiplus not rely on broken behaviour. -- Dmitry.

April 23, 2012

Re: [2/2] gdi32: Enumerated font size should not be too large.

by Huw Davies

On 23/04/2012 16:07, Dmitry Timoshkov wrote: > Huw Davies<huw(a)codeweavers.com> wrote: >> You'll need to fix the ntmTm.ntmCellHeight and ntmTm.ntmAvgWidth values. > > As far as I can see that code always have been that way, and reverted patch > didn't touch it either. But I see your point, and will add the tests (and > a fix if the tests prove it's correct) in a later patch. Perhaps the original commit was added to work around this issue? Note, you'll probably have to retrieve the metrics at the design size (2048) in order to get accurate values for these members. Simply up-scaling the values obtained at 100 ppem will lead to rounding errors. As you say, tests are needed. Huw.

April 23, 2012

Re: [2/2] gdi32: Enumerated font size should not be too large.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > > if(face->scalable) { > > - height = -2048; /* 2048 is the most common em size */ > > + height = 100; > > width = 0; > > } else { > > height = face->size.y_ppem>> 6; > > You'll need to fix the ntmTm.ntmCellHeight and ntmTm.ntmAvgWidth values. As far as I can see that code always have been that way, and reverted patch didn't touch it either. But I see your point, and will add the tests (and a fix if the tests prove it's correct) in a later patch. -- Dmitry.

April 23, 2012

Re: [2/2] gdi32: Enumerated font size should not be too large.

by Huw Davies

On 23/04/2012 15:32, Dmitry Timoshkov wrote: > This reverts commit f4625d1ae1109ee9a30faa8254b10779853f0ac2. > --- > dlls/gdi32/freetype.c | 2 +- > dlls/gdi32/tests/font.c | 1 + > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 3875e4f..401cfd1 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -5048,7 +5048,7 @@ static void GetEnumStructs(Face *face, LPENUMLOGFONTEXW pelf, > font = alloc_font(); > > if(face->scalable) { > - height = -2048; /* 2048 is the most common em size */ > + height = 100; > width = 0; > } else { > height = face->size.y_ppem>> 6; You'll need to fix the ntmTm.ntmCellHeight and ntmTm.ntmAvgWidth values. Huw.

April 23, 2012

Re: gdiplus: Use symbolic name of the font style.

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > > - INT fontstyle=0; > > + INT fontstyle = FontStyleRegular; > > > > if (!ntm) return 1; > > > Maybe it's better to make it 'enum FontStyle' after all. Current version is fine IMO, but feel free to send a patch :) -- Dmitry.

April 23, 2012

Re: [2/5] gdi32: Introduce a list of font file/data.

by Kusanagi Kouichi

On 2012-04-23 12:11:06 +0200, Alexandre Julliard wrote: > Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > > > @@ -962,6 +972,22 @@ static Family *find_family_from_any_name(const WCHAR *name) > > return NULL; > > } > > > > +static Font *find_font_file(const char *file) > > +{ > > + if (file != NULL) > > + { > > + Font *font; > > + > > + LIST_FOR_EACH_ENTRY(font, &font_list, Font, entry) > > + { > > + if (font->file != NULL && strcmp(font->file, file) == 0) > > + return font; > > + } > > + } > > + > > + return NULL; > > +} > > You can't compare files this way, different paths can point to the same > file. This function finds font path, not file. So find_font_path would be more appropriate name. > > @@ -2927,7 +2988,8 @@ static BOOL get_fontdir( const char *unix_name, struct fontdir *fd ) > > DWORD type; > > > > if (!ft_face) return FALSE; > > - face = create_face( ft_face, 0, unix_name, NULL, 0, 0, FALSE ); > > + font.file = (char *)unix_name; > > Don't do that. > > -- > Alexandre Julliard > julliard(a)winehq.org

April 23, 2012

Re: [PATCH 1/4] amstream: rename mediastream to ddrawmediastream. (resend)

by Christian Costa

2012/4/23 Alexandre Julliard <julliard(a)winehq.org> > Christian Costa <titan.costa(a)gmail.com> writes: > > > --- > > dlls/amstream/Makefile.in | 2 > > dlls/amstream/amstream.c | 6 + > > dlls/amstream/amstream_private.h | 2 > > dlls/amstream/ddrawmediastream.c | 256 > ++++++++++++++++++++++++++++++++++++++ > > dlls/amstream/mediastream.c | 251 > ------------------------------------- > > 5 files changed, 263 insertions(+), 254 deletions(-) > > create mode 100644 dlls/amstream/ddrawmediastream.c > > delete mode 100644 dlls/amstream/mediastream.c > > There's no reason to rename the file. Just put everything in there. > > Do you mean having DirectDrawMediaStream and AudioMediaStream in mediastream.c ? Ok I'll do that.

April 23, 2012

Re: iphlpapi: Move get_pid_map() and find_owning_pid() under #ifdef #ifdef __linux__.

by Alexandre Julliard

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > ...like their sole user. > > Otherwise this warns on everything which is not __linux__. ;-) That's a feature. It needs to be implemented on other platforms. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2012

Re: [2/5] gdi32: Introduce a list of font file/data.

by Alexandre Julliard

Kusanagi Kouichi <slash(a)ac.auone-net.jp> writes: > @@ -962,6 +972,22 @@ static Family *find_family_from_any_name(const WCHAR *name) > return NULL; > } > > +static Font *find_font_file(const char *file) > +{ > + if (file != NULL) > + { > + Font *font; > + > + LIST_FOR_EACH_ENTRY(font, &font_list, Font, entry) > + { > + if (font->file != NULL && strcmp(font->file, file) == 0) > + return font; > + } > + } > + > + return NULL; > +} You can't compare files this way, different paths can point to the same file. > @@ -2927,7 +2988,8 @@ static BOOL get_fontdir( const char *unix_name, struct fontdir *fd ) > DWORD type; > > if (!ft_face) return FALSE; > - face = create_face( ft_face, 0, unix_name, NULL, 0, 0, FALSE ); > + font.file = (char *)unix_name; Don't do that. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2012

Re: [PATCH 1/4] amstream: rename mediastream to ddrawmediastream. (resend)

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > --- > dlls/amstream/Makefile.in | 2 > dlls/amstream/amstream.c | 6 + > dlls/amstream/amstream_private.h | 2 > dlls/amstream/ddrawmediastream.c | 256 ++++++++++++++++++++++++++++++++++++++ > dlls/amstream/mediastream.c | 251 ------------------------------------- > 5 files changed, 263 insertions(+), 254 deletions(-) > create mode 100644 dlls/amstream/ddrawmediastream.c > delete mode 100644 dlls/amstream/mediastream.c There's no reason to rename the file. Just put everything in there. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2012

Re: [PATCH 2/3] dmusic: Pass creation parameters to DMUSIC_CreateDirectMusicBufferImpl then allocate data buffer and set format accordingly.

by Alexandre Julliard

Christian Costa <titan.costa(a)gmail.com> writes: > +HRESULT WINAPI DMUSIC_CreateDirectMusicBufferImpl(LPDMUS_BUFFERDESC desc, LPVOID* ret_iface) > +{ > + IDirectMusicBufferImpl* dmbuffer; > + > + TRACE("(%p, %p)\n", desc, ret_iface); > + > + dmbuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectMusicBufferImpl)); > + if (!dmbuffer) { > + *ret_iface = NULL; > + return E_OUTOFMEMORY; > + } > + > + dmbuffer->lpVtbl = &DirectMusicBuffer_Vtbl; > + dmbuffer->ref = 0; /* Will be inited by QueryInterface */ > + > + memcpy(&dmbuffer->format, &desc->guidBufferFormat, sizeof(GUID)); > + dmbuffer->size = (desc->cbBuffer + 3) & ~3; /* Buffer size must be multiple of 4 bytes */ > + > + dmbuffer->data = HeapAlloc(GetProcessHeap(), 0, sizeof(dmbuffer->size)); > + if (!dmbuffer->data) { > + HeapFree(GetProcessHeap(), 0, dmbuffer); > + *ret_iface = NULL; > + return E_OUTOFMEMORY; > + } > + > + return IDirectMusicBufferImpl_QueryInterface((LPDIRECTMUSICBUFFER)dmbuffer, &IID_IDirectMusicBuffer, ret_iface); While you are changing the function please also make it handle errors properly. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2012

Re: Mono packaging status

by Jacek Caban

On 4/20/12 11:29 PM, Scott Ritchie wrote: > On 4/19/12 1:54 AM, Jacek Caban wrote: >> Hi Vincent, >> >> On 04/19/12 00:12, Vincent Povirk wrote: >>> If for some reason you want to try it, the current version is at >>> https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. >>> I think I will need a new home for the binaries, because github only >>> gives me enough space for about 5 of them. So, uh, don't count on that >>> URL sticking around. >> >> The right place for this is probably SourceForge, like all our other >> downloads. That's a detail to be handler during the final release >> through. >> >> Cheers, >> Jacek >> >> > > Sourceforge only gives us limited space that you can get through via a > simple web URL. If we need Wine to automatically download this the > way it does Gecko, then doing a normal "release" via sourceforge might > not be enough (since Wine can't click through the page). This is why > we were using things like the budgetdedicated hosting service (which > is still available) in years past. I'm not sure what limited space you mean. We already have Wine Gecko on SourceForge and a redirecting script on source.winehq.org, which is used for automated downloads. AFAIK this way we don't have any limitations and, as far as Wine packages are concerned, we don't depend on any specific external mirror provider. Jacek

April 23, 2012

Re: [PATCH 2/3] dmsynth: Check the rigth CLSID to create the DirectMusicSynthSink object. (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17990 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

April 21, 2012

Re: winedbg and program stdout

by Eric Pouech

Le 21/04/2012 10:33, Ilya Basin a écrit : > When I debug a program with winedbg, it's output never goes to the > same terminal. If it's compiled with -mconsole, it goes to a new > console window; if compiled with -mwindows, the output is discarded. > Any way to change this behavior? > > > > if your debuggee is a CUI (compiled with -m console), then winedbg forces to have two consoles, one for winedbg, the other one for the debuggee program that's a decision. if you want to change this, remove the CREATE_NEW_CONSOLE flag in programs/winedbg/tgt_active.c (actually we could make this an optional behavior of winedbg to share the current console with debuggee's output) if your debuggee is a GUI, it's windows default behavior not to create automatically a console for this program you need to call AllocConsole() in your debuggee for that. and it that case, wine will likely have to create a new window for the console A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

April 21, 2012

winedbg and program stdout

by Ilya Basin

When I debug a program with winedbg, it's output never goes to the same terminal. If it's compiled with -mconsole, it goes to a new console window; if compiled with -mwindows, the output is discarded. Any way to change this behavior?

April 21, 2012

Re: Mono packaging status

by Scott Ritchie

On 4/19/12 1:54 AM, Jacek Caban wrote: > Hi Vincent, > > On 04/19/12 00:12, Vincent Povirk wrote: >> If for some reason you want to try it, the current version is at >> https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. >> I think I will need a new home for the binaries, because github only >> gives me enough space for about 5 of them. So, uh, don't count on that >> URL sticking around. > > The right place for this is probably SourceForge, like all our other > downloads. That's a detail to be handler during the final release through. > > Cheers, > Jacek > > Sourceforge only gives us limited space that you can get through via a simple web URL. If we need Wine to automatically download this the way it does Gecko, then doing a normal "release" via sourceforge might not be enough (since Wine can't click through the page). This is why we were using things like the budgetdedicated hosting service (which is still available) in years past. Thanks, Scott Ritchie

April 20, 2012

Re: d3dx9_36: Add adjacency for D3DXCreateCylinder

by Rico Schüller

Am 20.04.2012 16:20, schrieb David Adam: > > + if (adjacency) > > I'm not sure that this is correct, but why is adjacency not touched? What should be returned for adjacency, maybe a test will show it? I guess the temp ID3DXBuffer should be returned instead of leaked when all is successful... Cheers Rico

April 20, 2012

Re: jscript: Added regexp 'pre-parser' to support non-backslash-sequenced non-terminating '/' in characted classes

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17979 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 20, 2012

Re: Are we missing the small folder_open icons?

by Joel Holdsworth

Yes I agree, that FIXME looks strange. As you say, folder_icon.ico has all three icon sizes inside, so why is included in the resource three times? Does native have 3 icon resources? Is it ok to use the same multi-size icon 3 times? Joel On 20 April 2012 at 06:53 Francois Gouget <fgouget(a)free.fr> wrote: > > In dlls/shell32/shell32.rc I see the following fixme: > > /* FIXME: Following three resources are not yet added */ > /* @makedep: folder_open.ico */ > IDI_SHELL_FOLDER_OPEN_SMALL ICON folder_open.ico > /* @makedep: folder_open.ico */ > IDI_SHELL_FOLDER_OPEN_LARGE ICON folder_open.ico > /* @makedep: folder_open.ico */ > IDI_SHELL_FOLDER_SMALL_XP ICON folder_open.ico > > However folder_open.ico is generated from an SVG file and we seem to be > having it in multiple sizes. Also this fixme has been there forever. So > is there really still something to be fixed? > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > "Lotto: A tax on people who are bad at math." -- unknown > "Windows: Microsoft's tax on computer illiterates." -- WE7U > >

April 20, 2012

Are we missing the small folder_open icons?

by Francois Gouget

In dlls/shell32/shell32.rc I see the following fixme: /* FIXME: Following three resources are not yet added */ /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_SMALL ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_OPEN_LARGE ICON folder_open.ico /* @makedep: folder_open.ico */ IDI_SHELL_FOLDER_SMALL_XP ICON folder_open.ico However folder_open.ico is generated from an SVG file and we seem to be having it in multiple sizes. Also this fixme has been there forever. So is there really still something to be fixed? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

April 20, 2012

Re: Updating GSoC proposal

by Steven Edwards

On Tue, Mar 20, 2012 at 2:41 AM, Jacek Caban <cjacek(a)gmail.com> wrote: > > Cleanup Winemenubuilder to support generating Application Bundles on Mac > OS X There is a much better version of my patch for this on the morth-wine tree on GitHub. It just needs to be broken up and submitted by someone that cares. If a SoC student shows up with interest, please send them my way, I would be happy to help point them in the right direction. Our code works, I just don't have the time to break it up and get it in the tree. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

April 19, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by Andreas Dilger

On 2012-04-19, at 8:06 AM, David Howells wrote: > Add a pair of system calls to make extended file stats available, > including file creation time, inode version and data version where available through the underlying filesystem. > > The idea was initially proposed as a set of xattrs that could be > retrieved with getxattr(), but the general preferance proved to be > for new syscalls with an extended stat structure. I would comment that it was the opposite. It was originally a stat()-like extension that degraded into a messy getxattr() mess. > (2) Lightweight stat: Ask for just those details of interest, and > allow a netfs (such as NFS) to approximate anything not of > interest, possibly without going to the server [Trond Myklebust, > Ulrich Drepper]. This was my original motivation for this functionality, so you can put my name here also. > The fields in struct xstat come in a number of classes: > > (0) st_dev, st_blksize, st_information. > > These are local data and are always available. For the extra two bits it would cost us, I don't think st_blksize and st_information should always be returned. st_blksize may be variable for a distributed filesystem, and some of the fields in st_information (offline) may not be free to access either. Cheers, Andreas

April 19, 2012

Re: [PATCH 0/6] Extended file stat system call

by Andreas Dilger

On 2012-04-19, at 8:05 AM, David Howells wrote: > Implement a pair of new system calls to provide extended and further > extensible stat functions. Hallelujah for this. I've been waiting/wanting something like this for ages already. Now if only we can get this landed before it degrades into the mess it did last time. > Should fxstat() be implemented as xstat() with a NULL filename, > using dfd as fd? I'm personally inclined toward fewer syscalls, especially since the fstatxat()->statxat() mapping (if I can be so bold as to prefer the names used later in this thread) is IMHO clear and unambiguous, and avoids several thin wrappers in the kernel. > Should the default for a network fs be to do an unconditional > (heavyweight) stat with a flag to suppress going to the server > to update the locally held attributes and flushing pending writebacks? NOOOooo! If application writers are going to use this, they should request the information needed, and no more. Make no assumptions about what information is easy or hard for a filesystem to return, since the overhead can vary wildly depending on the implementation. Something like "ls --color" (no -l or -s) always stats the file just to get the mode bits to color executable files differently. Having to return other information that isn't totally free almost ruins the benefit of adding a new syscall in the first place. > Should things like the Windows Archive, Hidden and System bits be > handled through IOC flags, perhaps expanded to 64-bits? I'm definitely in favour of a 64-bit IOC flags value, since they are getting close to running out already. As to whether those other bits should be merged into the IOC flags, I'm mostly indifferent, but I lean toward including them since they are definitely related. I wouldn't object to 64-bit UID/GID values or split 32-bit low/hi UID and GID values, since NFSv4 and Kerberos realms will likely need this at some point as well. That said, if the API is extensible, it would be just as easy to add the low/hi split values when they are needed in the future. > Are these things useful to userspace other than Samba and userspace > NFS servers? Definitely yes. The GNU fileutils can use a lot of this, since they are VERY stat() heavy for things like checking st_dev and st_ino changes during directory traversal, but don't need any of the other info. > Is it useful to pass the volume ID out? Or is statfs() sufficient > for this? Can't hurt, IMHO. It is a better (more persistent) identifier than st_dev, and if it is free, or explicitly requested by the application (Samba, Ganesha, etc) it can be very useful. Cheers, Andreas

April 19, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

statx seems like a better family of names. I also think it's worthwhile to see if the interface can be made to more closely match the AIX precedent. Thanks, Roland

April 19, 2012

Re: [PATCH 0/6] Extended file stat system call

by Paul Eggert

On 04/19/2012 09:32 AM, Roland McGrath wrote: > I have no comment on the functionality. But "xstat" is probably a poor > choice of name. In AIX 7.1 the (similar) function is called statxat instead of xstat. The API isn't exactly the same, but it's the same basic idea. Might be worth looking at, not merely to see whether the API should be the same, but also to borrow good ideas even if not. http://pic.dhe.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.basetechref/do…

April 19, 2012

Re: d3dx9/tests: Add DDS pixel format tests for D3DXGetImageInfoFromFileInMemory.

by Józef Kucia

On Thu, Apr 19, 2012 at 9:22 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Donnerstag, 19. April 2012, 20:23:36 schrieb Matteo Bruni: >> I'm not sure that's a good idea. ddraw.h is not included in recent >> DirectX SDKs and the relevant definitions are "gone", as far as I >> know. So I think d3dx9 or its tests should not depend on that header. > Furthermore the ddraw.h types do not support volume textures, but d3dx9's .dds > support does. So one more reason to declare your own structures. > Yes, the DDS header has a field named dwDepth in place of dwBackBufferCount.

April 19, 2012

Re: d3dx9/tests: Add DDS pixel format tests for D3DXGetImageInfoFromFileInMemory.

by Józef Kucia

On Thu, Apr 19, 2012 at 8:23 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Il 19 aprile 2012 19:37, Józef Kucia <joseph.kucia(a)gmail.com> ha scritto: >> --- >> dlls/d3dx9_36/tests/surface.c | 65 +++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 65 insertions(+), 0 deletions(-) >> >> diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c >> index 87aa03e..51d6ebd 100644 >> --- a/dlls/d3dx9_36/tests/surface.c >> +++ b/dlls/d3dx9_36/tests/surface.c >> @@ -22,6 +22,8 @@ >> #include "wine/test.h" >> #include "d3dx9tex.h" >> #include "resources.h" >> +#undef MAKE_DDHRESULT >> +#include "ddraw.h" >> > > I'm not sure that's a good idea. ddraw.h is not included in recent > DirectX SDKs and the relevant definitions are "gone", as far as I > know. So I think d3dx9 or its tests should not depend on that header. > > I'd just (re)declare the stuff you need privately in the test source > file instead. You don't even need to use the same > types/defines/variables names as those from ddraw.h, you just have to > keep them compatible. > > On that point, I see that MSDN mentions the equivalent DDS_HEADER and > DDS_PIXELFORMAT structures > (http://msdn.microsoft.com/en-us/library/windows/desktop/bb943991%28v=vs.85%…) > except those don't seem to be defined in the MS headers either. I > guess you are free to use whatever names you like... I also had doubts about including ddraw.h but I was reluctant to duplicate the code. Thanks.

April 19, 2012

Re: d3dx9/tests: Add DDS pixel format tests for D3DXGetImageInfoFromFileInMemory.

by Stefan Dösinger

Am Donnerstag, 19. April 2012, 20:23:36 schrieb Matteo Bruni: > I'm not sure that's a good idea. ddraw.h is not included in recent > DirectX SDKs and the relevant definitions are "gone", as far as I > know. So I think d3dx9 or its tests should not depend on that header. Furthermore the ddraw.h types do not support volume textures, but d3dx9's .dds support does. So one more reason to declare your own structures.

April 19, 2012

Re: d3dx9/tests: Add DDS pixel format tests for D3DXGetImageInfoFromFileInMemory.

by Matteo Bruni

Il 19 aprile 2012 19:37, Józef Kucia <joseph.kucia(a)gmail.com> ha scritto: > --- > dlls/d3dx9_36/tests/surface.c | 65 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 65 insertions(+), 0 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/surface.c b/dlls/d3dx9_36/tests/surface.c > index 87aa03e..51d6ebd 100644 > --- a/dlls/d3dx9_36/tests/surface.c > +++ b/dlls/d3dx9_36/tests/surface.c > @@ -22,6 +22,8 @@ > #include "wine/test.h" > #include "d3dx9tex.h" > #include "resources.h" > +#undef MAKE_DDHRESULT > +#include "ddraw.h" > I'm not sure that's a good idea. ddraw.h is not included in recent DirectX SDKs and the relevant definitions are "gone", as far as I know. So I think d3dx9 or its tests should not depend on that header. I'd just (re)declare the stuff you need privately in the test source file instead. You don't even need to use the same types/defines/variables names as those from ddraw.h, you just have to keep them compatible. On that point, I see that MSDN mentions the equivalent DDS_HEADER and DDS_PIXELFORMAT structures (http://msdn.microsoft.com/en-us/library/windows/desktop/bb943991%28v=vs.85%…) except those don't seem to be defined in the MS headers either. I guess you are free to use whatever names you like...

April 19, 2012

Re: [PATCH 0/6] Extended file stat system call

by Steve French

On Thu, Apr 19, 2012 at 9:05 AM, David Howells <dhowells(a)redhat.com> wrote: > > Implement a pair of new system calls to provide extended and further extensible stat functions. <snip> > Should the default for a network fs be to do an unconditional (heavyweight) > stat with a flag to suppress going to the server to update the locally held > attributes and flushing pending writebacks? Even though we can use leases (oplocks) to avoid the roundrtrip, it is probably too expensive to default to forcing a cache flush, especially when a common case is to get the file creation time or inode number information (stable vs volatile). Would it be better to make the stable vs volatile inode number an attribute of the volume or something returned by the proposed xstat? > Should things like the Windows Archive, Hidden and System bits be handled > through IOC flags, perhaps expanded to 64-bits? Today I export these through an psuedo-xattr in cifs.ko, I am curious how NTFS and FAT export these on linux. > ========== > TO BE DONE > ========== > > Autofs, ntfs, btrfs, ... Given the overlap in optional attributes between the network protocol and local NTFS (and ReFS and to a lesser extent FAT) I would expect cifs.ko and the ntfs implementations info to map pretty closely. > I should perhaps use u8/u32/u64 rather than uint8/32/64_t. > > Handle remote filesystems being offline and indicate this with > XSTAT_INFO_OFFLINE. You already have support for an indicator for offline files (HSM), would XSTAT_INFO_OFFLINE be intended for the case where the network session to the server is disconnected (and in which you case the application does not want to reconnect)? -- Thanks, Steve

April 19, 2012

Re: [PATCH 0/6] Extended file stat system call

by Roland McGrath

I have no comment on the functionality. But "xstat" is probably a poor choice of name. There is precedent for that function name with different meaning in the userland APIs. (It's a moderately useless meaning inherited from SVR4, but regardless overloading a name previously used is unwise.) Thanks, Roland

April 19, 2012

Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

by Steve French

This patch reminds me of a question on time stamps - how can an application query the time granularity ie sb_s_time_gran for a mount (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1 nanosecond for others etc.) On Thu, Apr 19, 2012 at 9:06 AM, David Howells <dhowells(a)redhat.com> wrote: > Return extended attributes from the Ext4 filesystem. This includes the > following: > > (1) The inode creation time (i_crtime) as i_btime. > > (2) The inode i_generation as i_gen if not the root directory. > > (3) The inode i_version as st_data_version if a file with I_VERSION set or a > directory. > > (4) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS). > > Signed-off-by: David Howells <dhowells(a)redhat.com> > --- > > fs/ext4/ext4.h | 2 ++ > fs/ext4/file.c | 2 +- > fs/ext4/inode.c | 32 +++++++++++++++++++++++++++++--- > fs/ext4/namei.c | 2 ++ > fs/ext4/super.c | 1 + > fs/ext4/symlink.c | 2 ++ > 6 files changed, 37 insertions(+), 4 deletions(-) > > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h > index ab2594a..81806da 100644 > --- a/fs/ext4/ext4.h > +++ b/fs/ext4/ext4.h > @@ -1899,6 +1899,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, > struct kstat *stat); > extern void ext4_evict_inode(struct inode *); > extern void ext4_clear_inode(struct inode *); > +extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, > + struct kstat *stat); > extern int ext4_sync_inode(handle_t *, struct inode *); > extern void ext4_dirty_inode(struct inode *, int); > extern int ext4_change_inode_journal_flag(struct inode *, int); > diff --git a/fs/ext4/file.c b/fs/ext4/file.c > index cb70f18..ae8654c 100644 > --- a/fs/ext4/file.c > +++ b/fs/ext4/file.c > @@ -249,7 +249,7 @@ const struct file_operations ext4_file_operations = { > > const struct inode_operations ext4_file_inode_operations = { > .setattr = ext4_setattr, > - .getattr = ext4_getattr, > + .getattr = ext4_file_getattr, > #ifdef CONFIG_EXT4_FS_XATTR > .setxattr = generic_setxattr, > .getxattr = generic_getxattr, > diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c > index c77b0bd..eafc188 100644 > --- a/fs/ext4/inode.c > +++ b/fs/ext4/inode.c > @@ -4191,11 +4191,37 @@ err_out: > int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, > struct kstat *stat) > { > - struct inode *inode; > - unsigned long delalloc_blocks; > + struct inode *inode = dentry->d_inode; > + struct ext4_inode_info *ei = EXT4_I(inode); > + > + stat->result_mask |= XSTAT_BTIME; > + stat->btime.tv_sec = ei->i_crtime.tv_sec; > + stat->btime.tv_nsec = ei->i_crtime.tv_nsec; > + > + if (inode->i_ino != EXT4_ROOT_INO) { > + stat->result_mask |= XSTAT_GEN; > + stat->gen = inode->i_generation; > + } > + if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) { > + stat->result_mask |= XSTAT_VERSION; > + stat->version = inode->i_version; > + } > + > + ext4_get_inode_flags(ei); > + stat->ioc_flags |= ei->i_flags & EXT4_FL_USER_VISIBLE; > + stat->result_mask |= XSTAT_IOC_FLAGS; > > - inode = dentry->d_inode; > generic_fillattr(inode, stat); > + return 0; > +} > + > +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, > + struct kstat *stat) > +{ > + struct inode *inode = dentry->d_inode; > + u64 delalloc_blocks; > + > + ext4_getattr(mnt, dentry, stat); > > /* > * We can't update i_blocks if the block allocation is delayed > diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c > index 349d7b3..6162387 100644 > --- a/fs/ext4/namei.c > +++ b/fs/ext4/namei.c > @@ -2579,6 +2579,7 @@ const struct inode_operations ext4_dir_inode_operations = { > .mknod = ext4_mknod, > .rename = ext4_rename, > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > #ifdef CONFIG_EXT4_FS_XATTR > .setxattr = generic_setxattr, > .getxattr = generic_getxattr, > @@ -2591,6 +2592,7 @@ const struct inode_operations ext4_dir_inode_operations = { > > const struct inode_operations ext4_special_inode_operations = { > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > #ifdef CONFIG_EXT4_FS_XATTR > .setxattr = generic_setxattr, > .getxattr = generic_getxattr, > diff --git a/fs/ext4/super.c b/fs/ext4/super.c > index ceebaf8..2d395bf 100644 > --- a/fs/ext4/super.c > +++ b/fs/ext4/super.c > @@ -3040,6 +3040,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) > if (sb->s_magic != EXT4_SUPER_MAGIC) > goto cantfind_ext4; > sbi->s_kbytes_written = le64_to_cpu(es->s_kbytes_written); > + memcpy(sb->s_volume_id, es->s_uuid, sizeof(sb->s_volume_id)); > > /* Set defaults before we parse the mount options */ > def_mount_opts = le32_to_cpu(es->s_default_mount_opts); > diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c > index ed9354a..d8fe7fb 100644 > --- a/fs/ext4/symlink.c > +++ b/fs/ext4/symlink.c > @@ -35,6 +35,7 @@ const struct inode_operations ext4_symlink_inode_operations = { > .follow_link = page_follow_link_light, > .put_link = page_put_link, > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > #ifdef CONFIG_EXT4_FS_XATTR > .setxattr = generic_setxattr, > .getxattr = generic_getxattr, > @@ -47,6 +48,7 @@ const struct inode_operations ext4_fast_symlink_inode_operations = { > .readlink = generic_readlink, > .follow_link = ext4_follow_link, > .setattr = ext4_setattr, > + .getattr = ext4_getattr, > #ifdef CONFIG_EXT4_FS_XATTR > .setxattr = generic_setxattr, > .getxattr = generic_getxattr, > > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, Steve

April 19, 2012

Re: [PATCH 5/6] xstat: CIFS: Return extended attributes

by Steve French

For some of our users this would help A LOT. Interesting ... just had discussions yesterday with some guys trying to migrate to Linux and another set trying to backup Windows/NetApp from Linux. Some things they brought up that they needed (beyond what we already have wth the cifs acl and SID and "dos attributes" xattrs, which is even more useful now with the backup intent cifs mount flag) included: - how do they tell if the inode number for a file was manufactured on the client, or whether we were able to use the server file's inode number ("UniqueId") - how to get birth time (creation time) - how to tell if file is "offline" (HSM) - And is there a way to return the other less common cifs attributes (e.g. "reparse") Dave's patch seems to address all of that. Samba server stuffs most of this in an ndr encoded xattr blob which isn't much good for kernel code to use, and I really prefer Dave's approach. Without this, I would need to add another cifs specific ioctl, but since there is significant overlap between some of these and ntfs, vfat, nfs etc. I like the xstat idea better. On Thu, Apr 19, 2012 at 9:07 AM, David Howells <dhowells(a)redhat.com> wrote: > Return extended attributes from the CIFS filesystem. This includes the > following: > > (1) Return the file creation time as btime. We assume that the creation time > won't change over the life of the inode. > > (2) Set XSTAT_INFO_AUTOMOUNT on referral/submount directories. > > (3) Unset XSTAT_INO if we made up the inode number and didn't get it from the > server. > > (4) Unset XSTAT_[UG]ID if we are either returning values passed to mount > and/or the server doesn't return them. > > (5) Map various Windows file attributes to FS_xxx_FL flags in st_ioc_flags > and XSTAT_INFO_xxx flags in st_information, fetching them from the server > if we don't have them yet or don't have a current copy. > > Possibly things like Hidden, System and Archive should be FS_xxx_FL flags > rather than XSTAT_INFO_xxx flags and st_ioc_flags should be expanded to > 64 bits. > > (6) Set XSTAT_INFO_REMOTE on all files fetched by CIFS. > > (7) Set XSTAT_INFO_NONSYSTEM_OWNERSHIP on all files as they all have Windows > ownership details too. > > (8) Set XSTAT_INFO_HAS_ACL if CONFIG_CIFS_ACL=y as Windows ACLs are available > on the object. > > Furthermore, what cifs_getattr() does can be controlled as follows: > > (1) If AT_FORCE_ATTR_SYNC is indicated, or if the inode flags or creation time > are requested but not yet collected, then the attributes will be reread > unconditionally. > > (2) If the basic stats are requested or if the inode flags are requested and > have been collected previously, then the attributes will be reread if out > of date. > > (3) Otherwise the cached attributes will be used - even if expired - without > reference to the server. > > Note that cifs_revalidate_dentry() will issue an extra operation to get the > FILE_ALL_INFO in addition to the FILE_UNIX_BASIC_INFO if it needs to collect > creation time and attributes on behalf of cifs_getattr(). > > [NOTE: THIS PATCH IS UNTESTED!] > > Signed-off-by: David Howells <dhowells(a)redhat.com> > --- > > fs/cifs/cifsfs.h | 4 +- > fs/cifs/cifsglob.h | 16 +++++-- > fs/cifs/dir.c | 2 - > fs/cifs/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++------- > 4 files changed, 118 insertions(+), 24 deletions(-) > > diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h > index d1389bb..021e327 100644 > --- a/fs/cifs/cifsfs.h > +++ b/fs/cifs/cifsfs.h > @@ -56,9 +56,9 @@ extern int cifs_rmdir(struct inode *, struct dentry *); > extern int cifs_rename(struct inode *, struct dentry *, struct inode *, > struct dentry *); > extern int cifs_revalidate_file_attr(struct file *filp); > -extern int cifs_revalidate_dentry_attr(struct dentry *); > +extern int cifs_revalidate_dentry_attr(struct dentry *, bool, bool); > extern int cifs_revalidate_file(struct file *filp); > -extern int cifs_revalidate_dentry(struct dentry *); > +extern int cifs_revalidate_dentry(struct dentry *, bool, bool); > extern int cifs_invalidate_mapping(struct inode *inode); > extern int cifs_getattr(struct vfsmount *, struct dentry *, struct kstat *); > extern int cifs_setattr(struct dentry *, struct iattr *); > diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h > index 4ff6313..d3567da 100644 > --- a/fs/cifs/cifsglob.h > +++ b/fs/cifs/cifsglob.h > @@ -621,11 +621,15 @@ struct cifsInodeInfo { > /* BB add in lists for dirty pages i.e. write caching info for oplock */ > struct list_head openFileList; > __u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */ > - bool clientCanCacheRead; /* read oplock */ > - bool clientCanCacheAll; /* read and writebehind oplock */ > - bool delete_pending; /* DELETE_ON_CLOSE is set */ > - bool invalid_mapping; /* pagecache is invalid */ > + bool clientCanCacheRead:1; /* read oplock */ > + bool clientCanCacheAll:1; /* read and writebehind oplock */ > + bool delete_pending:1; /* DELETE_ON_CLOSE is set */ > + bool invalid_mapping:1; /* pagecache is invalid */ > + bool btime_valid:1; /* stored creation time is valid */ > + bool uid_faked:1; /* true if i_uid is faked */ > + bool gid_faked:1; /* true if i_gid is faked */ > unsigned long time; /* jiffies of last update of inode */ > + struct timespec btime; /* creation time */ > u64 server_eof; /* current file size on server -- protected by i_lock */ > u64 uniqueid; /* server inode number */ > u64 createtime; /* creation time on server */ > @@ -833,6 +837,9 @@ struct dfs_info3_param { > #define CIFS_FATTR_DELETE_PENDING 0x2 > #define CIFS_FATTR_NEED_REVAL 0x4 > #define CIFS_FATTR_INO_COLLISION 0x8 > +#define CIFS_FATTR_WINATTRS_VALID 0x10 /* T if cf_btime and cf_cifsattrs valid */ > +#define CIFS_FATTR_UID_FAKED 0x20 /* T if cf_uid is faked */ > +#define CIFS_FATTR_GID_FAKED 0x40 /* T if cf_gid is faked */ > > struct cifs_fattr { > u32 cf_flags; > @@ -850,6 +857,7 @@ struct cifs_fattr { > struct timespec cf_atime; > struct timespec cf_mtime; > struct timespec cf_ctime; > + struct timespec cf_btime; > }; > > static inline void free_dfs_info_param(struct dfs_info3_param *param) > diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c > index d172c8e..d9e03ae 100644 > --- a/fs/cifs/dir.c > +++ b/fs/cifs/dir.c > @@ -664,7 +664,7 @@ cifs_d_revalidate(struct dentry *direntry, struct nameidata *nd) > return -ECHILD; > > if (direntry->d_inode) { > - if (cifs_revalidate_dentry(direntry)) > + if (cifs_revalidate_dentry(direntry, false, false)) > return 0; > else { > /* > diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c > index 745da3d..662d5ce 100644 > --- a/fs/cifs/inode.c > +++ b/fs/cifs/inode.c > @@ -135,13 +135,21 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr) > set_nlink(inode, fattr->cf_nlink); > inode->i_uid = fattr->cf_uid; > inode->i_gid = fattr->cf_gid; > + if (fattr->cf_flags & CIFS_FATTR_UID_FAKED) > + cifs_i->uid_faked = true; > + if (fattr->cf_flags & CIFS_FATTR_GID_FAKED) > + cifs_i->gid_faked = true; > > /* if dynperm is set, don't clobber existing mode */ > if (inode->i_state & I_NEW || > !(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_DYNPERM)) > inode->i_mode = fattr->cf_mode; > > - cifs_i->cifsAttrs = fattr->cf_cifsattrs; > + if (fattr->cf_flags & CIFS_FATTR_WINATTRS_VALID) { > + cifs_i->cifsAttrs = fattr->cf_cifsattrs; > + cifs_i->btime = fattr->cf_btime; > + cifs_i->btime_valid = true; > + } > > if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL) > cifs_i->time = 0; > @@ -248,15 +256,19 @@ cifs_unix_basic_to_fattr(struct cifs_fattr *fattr, FILE_UNIX_BASIC_INFO *info, > break; > } > > - if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID) > + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID) { > fattr->cf_uid = cifs_sb->mnt_uid; > - else > + fattr->cf_flags |= CIFS_FATTR_UID_FAKED; > + } else { > fattr->cf_uid = le64_to_cpu(info->Uid); > + } > > - if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID) > + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID) { > fattr->cf_gid = cifs_sb->mnt_gid; > - else > + fattr->cf_flags |= CIFS_FATTR_GID_FAKED; > + } else { > fattr->cf_gid = le64_to_cpu(info->Gid); > + } > > fattr->cf_nlink = le64_to_cpu(info->Nlinks); > } > @@ -283,7 +295,8 @@ cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb) > fattr->cf_ctime = CURRENT_TIME; > fattr->cf_mtime = CURRENT_TIME; > fattr->cf_nlink = 2; > - fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL; > + fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL | > + CIFS_FATTR_UID_FAKED | CIFS_FATTR_GID_FAKED; > } > > int cifs_get_file_info_unix(struct file *filp) > @@ -510,6 +523,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info, > struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb); > > memset(fattr, 0, sizeof(*fattr)); > + fattr->cf_flags = CIFS_FATTR_WINATTRS_VALID; > fattr->cf_cifsattrs = le32_to_cpu(info->Attributes); > if (info->DeletePending) > fattr->cf_flags |= CIFS_FATTR_DELETE_PENDING; > @@ -521,6 +535,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info, > > fattr->cf_ctime = cifs_NTtimeToUnix(info->ChangeTime); > fattr->cf_mtime = cifs_NTtimeToUnix(info->LastWriteTime); > + fattr->cf_btime = cifs_NTtimeToUnix(info->CreationTime); > > if (adjust_tz) { > fattr->cf_ctime.tv_sec += tcon->ses->server->timeAdj; > @@ -1724,7 +1739,8 @@ int cifs_revalidate_file_attr(struct file *filp) > return rc; > } > > -int cifs_revalidate_dentry_attr(struct dentry *dentry) > +int cifs_revalidate_dentry_attr(struct dentry *dentry, > + bool want_extra_bits, bool force) > { > int xid; > int rc = 0; > @@ -1735,7 +1751,7 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry) > if (inode == NULL) > return -ENOENT; > > - if (!cifs_inode_needs_reval(inode)) > + if (!force && !cifs_inode_needs_reval(inode)) > return rc; > > xid = GetXid(); > @@ -1752,9 +1768,12 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry) > "%ld jiffies %ld", full_path, inode, inode->i_count.counter, > dentry, dentry->d_time, jiffies); > > - if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) > + if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) { > rc = cifs_get_inode_info_unix(&inode, full_path, sb, xid); > - else > + if (rc != 0) > + goto out; > + } > + if (!cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext || want_extra_bits) > rc = cifs_get_inode_info(&inode, full_path, NULL, sb, > xid, NULL); > > @@ -1779,12 +1798,13 @@ int cifs_revalidate_file(struct file *filp) > } > > /* revalidate a dentry's inode attributes */ > -int cifs_revalidate_dentry(struct dentry *dentry) > +int cifs_revalidate_dentry(struct dentry *dentry, > + bool want_extra_bits, bool force) > { > int rc; > struct inode *inode = dentry->d_inode; > > - rc = cifs_revalidate_dentry_attr(dentry); > + rc = cifs_revalidate_dentry_attr(dentry, want_extra_bits, force); > if (rc) > return rc; > > @@ -1796,11 +1816,30 @@ int cifs_revalidate_dentry(struct dentry *dentry) > int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry, > struct kstat *stat) > { > + struct cifsInodeInfo *cifs_i = CIFS_I(dentry->d_inode); > struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb); > struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb); > struct inode *inode = dentry->d_inode; > + unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC; > + bool want_extra_bits = false; > + u32 info, ioc = 0; > + u32 attrs; > int rc; > > + if (cifs_i->uid_faked) > + stat->request_mask &= ~XSTAT_UID; > + if (cifs_i->gid_faked) > + stat->request_mask &= ~XSTAT_GID; > + > + if (stat->request_mask & XSTAT_BTIME && !cifs_i->btime_valid) { > + want_extra_bits = true; > + force = true; > + } > + if (stat->request_mask & XSTAT_IOC_FLAGS) { > + want_extra_bits = true; > + force = true; > + } > + > /* > * We need to be sure that all dirty pages are written and the server > * has actual ctime, mtime and file length. > @@ -1814,13 +1853,14 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry, > } > } > > - rc = cifs_revalidate_dentry_attr(dentry); > - if (rc) > - return rc; > + if (force || stat->request_mask & XSTAT_BASIC_STATS) { > + rc = cifs_revalidate_dentry(dentry, want_extra_bits, force); > + if (rc) > + return rc; > + } > > generic_fillattr(inode, stat); > stat->blksize = CIFS_MAX_MSGSIZE; > - stat->ino = CIFS_I(inode)->uniqueid; > > /* > * If on a multiuser mount without unix extensions, and the admin hasn't > @@ -1834,7 +1874,53 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry, > if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)) > stat->gid = current_fsgid(); > } > - return rc; > + > + info = XSTAT_INFO_REMOTE | XSTAT_INFO_NONSYSTEM_OWNERSHIP; > +#ifdef CONFIG_CIFS_ACL > + info |= XSTAT_INFO_HAS_ACL; > +#endif > + > + if (cifs_i->btime_valid) { > + stat->btime = cifs_i->btime; > + stat->result_mask |= XSTAT_BTIME; > + } > + > + /* We don't promise an inode number if we made one up */ > + stat->ino = cifs_i->uniqueid; > + if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)) > + stat->result_mask &= ~XSTAT_INO; > + > + /* > + * If on a multiuser mount without unix extensions, and the admin > + * hasn't overridden them, set the ownership to the fsuid/fsgid of the > + * current process. > + */ > + if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MULTIUSER) && > + !tcon->unix_ext) { > + if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID)) > + stat->uid = current_fsuid(); > + if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)) > + stat->gid = current_fsgid(); > + } > + if (cifs_i->uid_faked) > + stat->result_mask &= ~XSTAT_UID; > + if (cifs_i->gid_faked) > + stat->result_mask &= ~XSTAT_GID; > + > + attrs = cifs_i->cifsAttrs; > + if (attrs & ATTR_HIDDEN) info |= XSTAT_INFO_HIDDEN; > + if (attrs & ATTR_SYSTEM) info |= XSTAT_INFO_SYSTEM; > + if (attrs & ATTR_ARCHIVE) info |= XSTAT_INFO_ARCHIVE; > + if (attrs & ATTR_TEMPORARY) info |= XSTAT_INFO_TEMPORARY; > + if (attrs & ATTR_REPARSE) info |= XSTAT_INFO_REPARSE_POINT; > + if (attrs & ATTR_OFFLINE) info |= XSTAT_INFO_OFFLINE; > + if (attrs & ATTR_ENCRYPTED) info |= XSTAT_INFO_ENCRYPTED; > + stat->information |= info; > + > + if (attrs & ATTR_READONLY) ioc |= FS_IMMUTABLE_FL; > + if (attrs & ATTR_COMPRESSED) ioc |= FS_COMPR_FL; > + stat->ioc_flags |= ioc; > + return 0; > } > > static int cifs_truncate_page(struct address_space *mapping, loff_t from) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Thanks, Steve

April 19, 2012

Re: [PATCH 4/6] xstat: NFS: Return extended attributes

by Myklebust, Trond

On Thu, 2012-04-19 at 15:06 +0100, David Howells wrote: > Return extended attributes from the NFS filesystem. This includes the > following: > > (1) The change attribute as st_data_version if NFSv4. > > (2) XSTAT_INFO_AUTOMOUNT and XSTAT_INFO_FABRICATED are set on referral or > submount directories that are automounted upon. NFS shows one directory > with a different FSID, but the local filesystem has two: the mountpoint > directory and the root of the filesystem mounted upon it. > > (3) XSTAT_INFO_REMOTE is set on files acquired over NFS. > > Furthermore, what nfs_getattr() does can be controlled as follows: > > (1) If AT_FORCE_ATTR_SYNC is indicated, or mtime, ctime or data_version (NFSv4 > only) are requested then the outstanding writes will be written to the > server first. > > (2) The inode's attributes may be synchronised with the server: > > (a) If AT_FORCE_ATTR_SYNC is indicated or if atime is requested (and atime > updating is not suppressed by a mount flag) then the attributes will > be reread unconditionally. > > (b) If the data version or any of basic stats are requested then the > attributes will be reread if the cached attributes have expired. > > (c) Otherwise the cached attributes will be used - even if expired - > without reference to the server. Hmm... As far as I can see you are still doing an nfs_revalidate_inode() in the non-forced case. That will cause expired attributes to be retrieved from the server. > Signed-off-by: David Howells <dhowells(a)redhat.com> > --- > > fs/nfs/inode.c | 49 +++++++++++++++++++++++++++++++++++++------------ > fs/nfs/super.c | 1 + > 2 files changed, 38 insertions(+), 12 deletions(-) > > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c > index e8bbfa5..460fcf3 100644 > --- a/fs/nfs/inode.c > +++ b/fs/nfs/inode.c > @@ -509,11 +509,18 @@ void nfs_setattr_update_inode(struct inode *inode, struct iattr *attr) > int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) > { > struct inode *inode = dentry->d_inode; > + unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC; > int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME; > int err; > > - /* Flush out writes to the server in order to update c/mtime. */ > - if (S_ISREG(inode->i_mode)) { > + if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4) > + stat->request_mask &= ~XSTAT_VERSION; > + > + /* Flush out writes to the server in order to update c/mtime > + * or data version if the user wants them */ > + if ((force || (stat->request_mask & > + (XSTAT_MTIME | XSTAT_CTIME | XSTAT_VERSION))) && > + S_ISREG(inode->i_mode)) { > err = filemap_write_and_wait(inode->i_mapping); We can get rid of the filemap_write_and_wait() if the caller allows us to approximate m/ctime values. That would give a major speed-up for most stat() workloads. > if (err) > goto out; > @@ -528,18 +535,36 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) > * - NFS never sets MS_NOATIME or MS_NODIRATIME so there is > * no point in checking those. > */ > - if ((mnt->mnt_flags & MNT_NOATIME) || > - ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))) > + if (mnt->mnt_flags & MNT_NOATIME || > + (mnt->mnt_flags & MNT_NODIRATIME && S_ISDIR(inode->i_mode))) { > + stat->ioc_flags |= FS_NOATIME_FL; > + need_atime = 0; > + } else if (!(stat->request_mask & XSTAT_ATIME)) { > need_atime = 0; > + } > > - if (need_atime) > - err = __nfs_revalidate_inode(NFS_SERVER(inode), inode); > - else > - err = nfs_revalidate_inode(NFS_SERVER(inode), inode); > - if (!err) { > - generic_fillattr(inode, stat); > - stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); > + if (force || stat->request_mask & (XSTAT_BASIC_STATS | XSTAT_VERSION)) { > + if (force || need_atime) > + err = __nfs_revalidate_inode(NFS_SERVER(inode), inode); > + else > + err = nfs_revalidate_inode(NFS_SERVER(inode), inode); > + if (err) > + goto out; > } > + > + generic_fillattr(inode, stat); > + stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); > + > + if (stat->request_mask & XSTAT_VERSION) { > + stat->version = inode->i_version; > + stat->result_mask |= XSTAT_VERSION; > + } > + > + if (IS_AUTOMOUNT(inode)) > + stat->information |= XSTAT_INFO_FABRICATED; > + > + stat->information |= XSTAT_INFO_REMOTE; > + > out: > return err; > } > @@ -852,7 +877,7 @@ int nfs_revalidate_inode(struct nfs_server *server, struct inode *inode) > static int nfs_invalidate_mapping(struct inode *inode, struct address_space *mapping) > { > struct nfs_inode *nfsi = NFS_I(inode); > - > + > if (mapping->nrpages != 0) { > int ret = invalidate_inode_pages2(mapping); > if (ret < 0) > diff --git a/fs/nfs/super.c b/fs/nfs/super.c > index 37412f7..faa652c 100644 > --- a/fs/nfs/super.c > +++ b/fs/nfs/super.c > @@ -2222,6 +2222,7 @@ static int nfs_set_super(struct super_block *s, void *data) > ret = set_anon_super(s, server); > if (ret == 0) > server->s_dev = s->s_dev; > + memcpy(&s->s_volume_id, &server->fsid, sizeof(s->s_volume_id)); > return ret; > } > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust(a)netapp.com www.netapp.com

April 19, 2012

[PATCH 6/6] xstat: eCryptFS: Return extended attributes

by David Howells

Return extended attributes from the eCryptFS filesystem, dredged up from the lower filesystem. XSTAT_INFO_ENCRYPTED is set on the files whose cryptography is handled by eCryptFS. Possibly eCryptFS should also set FS_COMPR_FL on its compressed files. Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/ecryptfs/inode.c | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index ab35b11..62865e9 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -1060,13 +1060,23 @@ int ecryptfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat lower_stat; int rc; - rc = vfs_getattr(ecryptfs_dentry_to_lower_mnt(dentry), - ecryptfs_dentry_to_lower(dentry), &lower_stat); + lower_stat.query_flags = stat->query_flags; + lower_stat.request_mask = stat->request_mask | XSTAT_BLOCKS; + rc = vfs_xgetattr(ecryptfs_dentry_to_lower_mnt(dentry), + ecryptfs_dentry_to_lower(dentry), &lower_stat); if (!rc) { fsstack_copy_attr_all(dentry->d_inode, ecryptfs_inode_to_lower(dentry->d_inode)); generic_fillattr(dentry->d_inode, stat); stat->blocks = lower_stat.blocks; + stat->result_mask = lower_stat.result_mask; + stat->information = lower_stat.information; + stat->information |= XSTAT_INFO_ENCRYPTED; + stat->gen = lower_stat.gen; + stat->version = lower_stat.version; + stat->ioc_flags = lower_stat.ioc_flags; + memcpy(&stat->volume_id, lower_stat.volume_id, + sizeof(stat->volume_id)); } return rc; }

April 19, 2012

[PATCH 5/6] xstat: CIFS: Return extended attributes

by David Howells

Return extended attributes from the CIFS filesystem. This includes the following: (1) Return the file creation time as btime. We assume that the creation time won't change over the life of the inode. (2) Set XSTAT_INFO_AUTOMOUNT on referral/submount directories. (3) Unset XSTAT_INO if we made up the inode number and didn't get it from the server. (4) Unset XSTAT_[UG]ID if we are either returning values passed to mount and/or the server doesn't return them. (5) Map various Windows file attributes to FS_xxx_FL flags in st_ioc_flags and XSTAT_INFO_xxx flags in st_information, fetching them from the server if we don't have them yet or don't have a current copy. Possibly things like Hidden, System and Archive should be FS_xxx_FL flags rather than XSTAT_INFO_xxx flags and st_ioc_flags should be expanded to 64 bits. (6) Set XSTAT_INFO_REMOTE on all files fetched by CIFS. (7) Set XSTAT_INFO_NONSYSTEM_OWNERSHIP on all files as they all have Windows ownership details too. (8) Set XSTAT_INFO_HAS_ACL if CONFIG_CIFS_ACL=y as Windows ACLs are available on the object. Furthermore, what cifs_getattr() does can be controlled as follows: (1) If AT_FORCE_ATTR_SYNC is indicated, or if the inode flags or creation time are requested but not yet collected, then the attributes will be reread unconditionally. (2) If the basic stats are requested or if the inode flags are requested and have been collected previously, then the attributes will be reread if out of date. (3) Otherwise the cached attributes will be used - even if expired - without reference to the server. Note that cifs_revalidate_dentry() will issue an extra operation to get the FILE_ALL_INFO in addition to the FILE_UNIX_BASIC_INFO if it needs to collect creation time and attributes on behalf of cifs_getattr(). [NOTE: THIS PATCH IS UNTESTED!] Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/cifs/cifsfs.h | 4 +- fs/cifs/cifsglob.h | 16 +++++-- fs/cifs/dir.c | 2 - fs/cifs/inode.c | 120 +++++++++++++++++++++++++++++++++++++++++++++------- 4 files changed, 118 insertions(+), 24 deletions(-) diff --git a/fs/cifs/cifsfs.h b/fs/cifs/cifsfs.h index d1389bb..021e327 100644 --- a/fs/cifs/cifsfs.h +++ b/fs/cifs/cifsfs.h @@ -56,9 +56,9 @@ extern int cifs_rmdir(struct inode *, struct dentry *); extern int cifs_rename(struct inode *, struct dentry *, struct inode *, struct dentry *); extern int cifs_revalidate_file_attr(struct file *filp); -extern int cifs_revalidate_dentry_attr(struct dentry *); +extern int cifs_revalidate_dentry_attr(struct dentry *, bool, bool); extern int cifs_revalidate_file(struct file *filp); -extern int cifs_revalidate_dentry(struct dentry *); +extern int cifs_revalidate_dentry(struct dentry *, bool, bool); extern int cifs_invalidate_mapping(struct inode *inode); extern int cifs_getattr(struct vfsmount *, struct dentry *, struct kstat *); extern int cifs_setattr(struct dentry *, struct iattr *); diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index 4ff6313..d3567da 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -621,11 +621,15 @@ struct cifsInodeInfo { /* BB add in lists for dirty pages i.e. write caching info for oplock */ struct list_head openFileList; __u32 cifsAttrs; /* e.g. DOS archive bit, sparse, compressed, system */ - bool clientCanCacheRead; /* read oplock */ - bool clientCanCacheAll; /* read and writebehind oplock */ - bool delete_pending; /* DELETE_ON_CLOSE is set */ - bool invalid_mapping; /* pagecache is invalid */ + bool clientCanCacheRead:1; /* read oplock */ + bool clientCanCacheAll:1; /* read and writebehind oplock */ + bool delete_pending:1; /* DELETE_ON_CLOSE is set */ + bool invalid_mapping:1; /* pagecache is invalid */ + bool btime_valid:1; /* stored creation time is valid */ + bool uid_faked:1; /* true if i_uid is faked */ + bool gid_faked:1; /* true if i_gid is faked */ unsigned long time; /* jiffies of last update of inode */ + struct timespec btime; /* creation time */ u64 server_eof; /* current file size on server -- protected by i_lock */ u64 uniqueid; /* server inode number */ u64 createtime; /* creation time on server */ @@ -833,6 +837,9 @@ struct dfs_info3_param { #define CIFS_FATTR_DELETE_PENDING 0x2 #define CIFS_FATTR_NEED_REVAL 0x4 #define CIFS_FATTR_INO_COLLISION 0x8 +#define CIFS_FATTR_WINATTRS_VALID 0x10 /* T if cf_btime and cf_cifsattrs valid */ +#define CIFS_FATTR_UID_FAKED 0x20 /* T if cf_uid is faked */ +#define CIFS_FATTR_GID_FAKED 0x40 /* T if cf_gid is faked */ struct cifs_fattr { u32 cf_flags; @@ -850,6 +857,7 @@ struct cifs_fattr { struct timespec cf_atime; struct timespec cf_mtime; struct timespec cf_ctime; + struct timespec cf_btime; }; static inline void free_dfs_info_param(struct dfs_info3_param *param) diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c index d172c8e..d9e03ae 100644 --- a/fs/cifs/dir.c +++ b/fs/cifs/dir.c @@ -664,7 +664,7 @@ cifs_d_revalidate(struct dentry *direntry, struct nameidata *nd) return -ECHILD; if (direntry->d_inode) { - if (cifs_revalidate_dentry(direntry)) + if (cifs_revalidate_dentry(direntry, false, false)) return 0; else { /* diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index 745da3d..662d5ce 100644 --- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -135,13 +135,21 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr) set_nlink(inode, fattr->cf_nlink); inode->i_uid = fattr->cf_uid; inode->i_gid = fattr->cf_gid; + if (fattr->cf_flags & CIFS_FATTR_UID_FAKED) + cifs_i->uid_faked = true; + if (fattr->cf_flags & CIFS_FATTR_GID_FAKED) + cifs_i->gid_faked = true; /* if dynperm is set, don't clobber existing mode */ if (inode->i_state & I_NEW || !(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_DYNPERM)) inode->i_mode = fattr->cf_mode; - cifs_i->cifsAttrs = fattr->cf_cifsattrs; + if (fattr->cf_flags & CIFS_FATTR_WINATTRS_VALID) { + cifs_i->cifsAttrs = fattr->cf_cifsattrs; + cifs_i->btime = fattr->cf_btime; + cifs_i->btime_valid = true; + } if (fattr->cf_flags & CIFS_FATTR_NEED_REVAL) cifs_i->time = 0; @@ -248,15 +256,19 @@ cifs_unix_basic_to_fattr(struct cifs_fattr *fattr, FILE_UNIX_BASIC_INFO *info, break; } - if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID) + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID) { fattr->cf_uid = cifs_sb->mnt_uid; - else + fattr->cf_flags |= CIFS_FATTR_UID_FAKED; + } else { fattr->cf_uid = le64_to_cpu(info->Uid); + } - if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID) + if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID) { fattr->cf_gid = cifs_sb->mnt_gid; - else + fattr->cf_flags |= CIFS_FATTR_GID_FAKED; + } else { fattr->cf_gid = le64_to_cpu(info->Gid); + } fattr->cf_nlink = le64_to_cpu(info->Nlinks); } @@ -283,7 +295,8 @@ cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb) fattr->cf_ctime = CURRENT_TIME; fattr->cf_mtime = CURRENT_TIME; fattr->cf_nlink = 2; - fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL; + fattr->cf_flags |= CIFS_FATTR_DFS_REFERRAL | + CIFS_FATTR_UID_FAKED | CIFS_FATTR_GID_FAKED; } int cifs_get_file_info_unix(struct file *filp) @@ -510,6 +523,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info, struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb); memset(fattr, 0, sizeof(*fattr)); + fattr->cf_flags = CIFS_FATTR_WINATTRS_VALID; fattr->cf_cifsattrs = le32_to_cpu(info->Attributes); if (info->DeletePending) fattr->cf_flags |= CIFS_FATTR_DELETE_PENDING; @@ -521,6 +535,7 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info, fattr->cf_ctime = cifs_NTtimeToUnix(info->ChangeTime); fattr->cf_mtime = cifs_NTtimeToUnix(info->LastWriteTime); + fattr->cf_btime = cifs_NTtimeToUnix(info->CreationTime); if (adjust_tz) { fattr->cf_ctime.tv_sec += tcon->ses->server->timeAdj; @@ -1724,7 +1739,8 @@ int cifs_revalidate_file_attr(struct file *filp) return rc; } -int cifs_revalidate_dentry_attr(struct dentry *dentry) +int cifs_revalidate_dentry_attr(struct dentry *dentry, + bool want_extra_bits, bool force) { int xid; int rc = 0; @@ -1735,7 +1751,7 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry) if (inode == NULL) return -ENOENT; - if (!cifs_inode_needs_reval(inode)) + if (!force && !cifs_inode_needs_reval(inode)) return rc; xid = GetXid(); @@ -1752,9 +1768,12 @@ int cifs_revalidate_dentry_attr(struct dentry *dentry) "%ld jiffies %ld", full_path, inode, inode->i_count.counter, dentry, dentry->d_time, jiffies); - if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) + if (cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext) { rc = cifs_get_inode_info_unix(&inode, full_path, sb, xid); - else + if (rc != 0) + goto out; + } + if (!cifs_sb_master_tcon(CIFS_SB(sb))->unix_ext || want_extra_bits) rc = cifs_get_inode_info(&inode, full_path, NULL, sb, xid, NULL); @@ -1779,12 +1798,13 @@ int cifs_revalidate_file(struct file *filp) } /* revalidate a dentry's inode attributes */ -int cifs_revalidate_dentry(struct dentry *dentry) +int cifs_revalidate_dentry(struct dentry *dentry, + bool want_extra_bits, bool force) { int rc; struct inode *inode = dentry->d_inode; - rc = cifs_revalidate_dentry_attr(dentry); + rc = cifs_revalidate_dentry_attr(dentry, want_extra_bits, force); if (rc) return rc; @@ -1796,11 +1816,30 @@ int cifs_revalidate_dentry(struct dentry *dentry) int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { + struct cifsInodeInfo *cifs_i = CIFS_I(dentry->d_inode); struct cifs_sb_info *cifs_sb = CIFS_SB(dentry->d_sb); struct cifs_tcon *tcon = cifs_sb_master_tcon(cifs_sb); struct inode *inode = dentry->d_inode; + unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC; + bool want_extra_bits = false; + u32 info, ioc = 0; + u32 attrs; int rc; + if (cifs_i->uid_faked) + stat->request_mask &= ~XSTAT_UID; + if (cifs_i->gid_faked) + stat->request_mask &= ~XSTAT_GID; + + if (stat->request_mask & XSTAT_BTIME && !cifs_i->btime_valid) { + want_extra_bits = true; + force = true; + } + if (stat->request_mask & XSTAT_IOC_FLAGS) { + want_extra_bits = true; + force = true; + } + /* * We need to be sure that all dirty pages are written and the server * has actual ctime, mtime and file length. @@ -1814,13 +1853,14 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry, } } - rc = cifs_revalidate_dentry_attr(dentry); - if (rc) - return rc; + if (force || stat->request_mask & XSTAT_BASIC_STATS) { + rc = cifs_revalidate_dentry(dentry, want_extra_bits, force); + if (rc) + return rc; + } generic_fillattr(inode, stat); stat->blksize = CIFS_MAX_MSGSIZE; - stat->ino = CIFS_I(inode)->uniqueid; /* * If on a multiuser mount without unix extensions, and the admin hasn't @@ -1834,7 +1874,53 @@ int cifs_getattr(struct vfsmount *mnt, struct dentry *dentry, if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)) stat->gid = current_fsgid(); } - return rc; + + info = XSTAT_INFO_REMOTE | XSTAT_INFO_NONSYSTEM_OWNERSHIP; +#ifdef CONFIG_CIFS_ACL + info |= XSTAT_INFO_HAS_ACL; +#endif + + if (cifs_i->btime_valid) { + stat->btime = cifs_i->btime; + stat->result_mask |= XSTAT_BTIME; + } + + /* We don't promise an inode number if we made one up */ + stat->ino = cifs_i->uniqueid; + if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SERVER_INUM)) + stat->result_mask &= ~XSTAT_INO; + + /* + * If on a multiuser mount without unix extensions, and the admin + * hasn't overridden them, set the ownership to the fsuid/fsgid of the + * current process. + */ + if ((cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MULTIUSER) && + !tcon->unix_ext) { + if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_UID)) + stat->uid = current_fsuid(); + if (!(cifs_sb->mnt_cifs_flags & CIFS_MOUNT_OVERR_GID)) + stat->gid = current_fsgid(); + } + if (cifs_i->uid_faked) + stat->result_mask &= ~XSTAT_UID; + if (cifs_i->gid_faked) + stat->result_mask &= ~XSTAT_GID; + + attrs = cifs_i->cifsAttrs; + if (attrs & ATTR_HIDDEN) info |= XSTAT_INFO_HIDDEN; + if (attrs & ATTR_SYSTEM) info |= XSTAT_INFO_SYSTEM; + if (attrs & ATTR_ARCHIVE) info |= XSTAT_INFO_ARCHIVE; + if (attrs & ATTR_TEMPORARY) info |= XSTAT_INFO_TEMPORARY; + if (attrs & ATTR_REPARSE) info |= XSTAT_INFO_REPARSE_POINT; + if (attrs & ATTR_OFFLINE) info |= XSTAT_INFO_OFFLINE; + if (attrs & ATTR_ENCRYPTED) info |= XSTAT_INFO_ENCRYPTED; + stat->information |= info; + + if (attrs & ATTR_READONLY) ioc |= FS_IMMUTABLE_FL; + if (attrs & ATTR_COMPRESSED) ioc |= FS_COMPR_FL; + stat->ioc_flags |= ioc; + return 0; } static int cifs_truncate_page(struct address_space *mapping, loff_t from)

April 19, 2012

[PATCH 4/6] xstat: NFS: Return extended attributes

by David Howells

Return extended attributes from the NFS filesystem. This includes the following: (1) The change attribute as st_data_version if NFSv4. (2) XSTAT_INFO_AUTOMOUNT and XSTAT_INFO_FABRICATED are set on referral or submount directories that are automounted upon. NFS shows one directory with a different FSID, but the local filesystem has two: the mountpoint directory and the root of the filesystem mounted upon it. (3) XSTAT_INFO_REMOTE is set on files acquired over NFS. Furthermore, what nfs_getattr() does can be controlled as follows: (1) If AT_FORCE_ATTR_SYNC is indicated, or mtime, ctime or data_version (NFSv4 only) are requested then the outstanding writes will be written to the server first. (2) The inode's attributes may be synchronised with the server: (a) If AT_FORCE_ATTR_SYNC is indicated or if atime is requested (and atime updating is not suppressed by a mount flag) then the attributes will be reread unconditionally. (b) If the data version or any of basic stats are requested then the attributes will be reread if the cached attributes have expired. (c) Otherwise the cached attributes will be used - even if expired - without reference to the server. Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/nfs/inode.c | 49 +++++++++++++++++++++++++++++++++++++------------ fs/nfs/super.c | 1 + 2 files changed, 38 insertions(+), 12 deletions(-) diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index e8bbfa5..460fcf3 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -509,11 +509,18 @@ void nfs_setattr_update_inode(struct inode *inode, struct iattr *attr) int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { struct inode *inode = dentry->d_inode; + unsigned force = stat->query_flags & AT_FORCE_ATTR_SYNC; int need_atime = NFS_I(inode)->cache_validity & NFS_INO_INVALID_ATIME; int err; - /* Flush out writes to the server in order to update c/mtime. */ - if (S_ISREG(inode->i_mode)) { + if (NFS_SERVER(inode)->nfs_client->rpc_ops->version < 4) + stat->request_mask &= ~XSTAT_VERSION; + + /* Flush out writes to the server in order to update c/mtime + * or data version if the user wants them */ + if ((force || (stat->request_mask & + (XSTAT_MTIME | XSTAT_CTIME | XSTAT_VERSION))) && + S_ISREG(inode->i_mode)) { err = filemap_write_and_wait(inode->i_mapping); if (err) goto out; @@ -528,18 +535,36 @@ int nfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) * - NFS never sets MS_NOATIME or MS_NODIRATIME so there is * no point in checking those. */ - if ((mnt->mnt_flags & MNT_NOATIME) || - ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))) + if (mnt->mnt_flags & MNT_NOATIME || + (mnt->mnt_flags & MNT_NODIRATIME && S_ISDIR(inode->i_mode))) { + stat->ioc_flags |= FS_NOATIME_FL; + need_atime = 0; + } else if (!(stat->request_mask & XSTAT_ATIME)) { need_atime = 0; + } - if (need_atime) - err = __nfs_revalidate_inode(NFS_SERVER(inode), inode); - else - err = nfs_revalidate_inode(NFS_SERVER(inode), inode); - if (!err) { - generic_fillattr(inode, stat); - stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); + if (force || stat->request_mask & (XSTAT_BASIC_STATS | XSTAT_VERSION)) { + if (force || need_atime) + err = __nfs_revalidate_inode(NFS_SERVER(inode), inode); + else + err = nfs_revalidate_inode(NFS_SERVER(inode), inode); + if (err) + goto out; } + + generic_fillattr(inode, stat); + stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode)); + + if (stat->request_mask & XSTAT_VERSION) { + stat->version = inode->i_version; + stat->result_mask |= XSTAT_VERSION; + } + + if (IS_AUTOMOUNT(inode)) + stat->information |= XSTAT_INFO_FABRICATED; + + stat->information |= XSTAT_INFO_REMOTE; + out: return err; } @@ -852,7 +877,7 @@ int nfs_revalidate_inode(struct nfs_server *server, struct inode *inode) static int nfs_invalidate_mapping(struct inode *inode, struct address_space *mapping) { struct nfs_inode *nfsi = NFS_I(inode); - + if (mapping->nrpages != 0) { int ret = invalidate_inode_pages2(mapping); if (ret < 0) diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 37412f7..faa652c 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2222,6 +2222,7 @@ static int nfs_set_super(struct super_block *s, void *data) ret = set_anon_super(s, server); if (ret == 0) server->s_dev = s->s_dev; + memcpy(&s->s_volume_id, &server->fsid, sizeof(s->s_volume_id)); return ret; }

April 19, 2012

[PATCH 3/6] xstat: AFS: Return extended attributes

by David Howells

Return extended attributes from the AFS filesystem. This includes the following: (1) The vnode uniquifier as st_gen. (2) The data version number as st_data_version. (3) XSTAT_INFO_AUTOMOUNT will be set on automount directories by virtue of S_AUTOMOUNT being set on the inode. These are referrals to other volumes or other cells. (4) XSTAT_INFO_AUTODIR on a directory that does cell lookup for non-existent names and mounts them (typically mounted on /afs with -o autocell). The resulting directories are marked XSTAT_INFO_FABRICATED as they do not actually exist in the mounted AFS directory. (6) Files, directories and symlinks accessed over AFS are marked XSTAT_INFO_REMOTE. (7) XSTAT_INFO_NONSYSTEM_OWNERSHIP is set as the UID and GID retrieved from an AFS share may not be applicable on the system. (8) XSTAT_INFO_HAS_ACL is set as AFS directories have ACLs (the UID and GID are only used through the ACLs) and these ACLs apply to the contents of the directories. Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/afs/inode.c | 29 +++++++++++++++++++++-------- fs/afs/super.c | 7 +++++++ 2 files changed, 28 insertions(+), 8 deletions(-) diff --git a/fs/afs/inode.c b/fs/afs/inode.c index d890ae3..062def2 100644 --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -71,9 +71,9 @@ static int afs_inode_map_status(struct afs_vnode *vnode, struct key *key) inode->i_uid = vnode->status.owner; inode->i_gid = 0; inode->i_size = vnode->status.size; - inode->i_ctime.tv_sec = vnode->status.mtime_server; - inode->i_ctime.tv_nsec = 0; - inode->i_atime = inode->i_mtime = inode->i_ctime; + inode->i_mtime.tv_sec = vnode->status.mtime_server; + inode->i_mtime.tv_nsec = 0; + inode->i_atime = inode->i_ctime = inode->i_mtime; inode->i_blocks = 0; inode->i_generation = vnode->fid.unique; inode->i_version = vnode->status.data_version; @@ -374,16 +374,29 @@ error_unlock: /* * read the attributes of an inode */ -int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, - struct kstat *stat) +int afs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { - struct inode *inode; - - inode = dentry->d_inode; + struct inode *inode = dentry->d_inode; _enter("{ ino=%lu v=%u }", inode->i_ino, inode->i_generation); generic_fillattr(inode, stat); + + stat->result_mask &= ~(XSTAT_ATIME | XSTAT_CTIME | XSTAT_BLOCKS); + stat->result_mask |= XSTAT_GEN | XSTAT_VERSION; + stat->gen = inode->i_generation; + stat->version = inode->i_version; + + if (test_bit(AFS_VNODE_AUTOCELL, &AFS_FS_I(inode)->flags)) + stat->information |= XSTAT_INFO_AUTODIR; + + if (test_bit(AFS_VNODE_PSEUDODIR, &AFS_FS_I(inode)->flags)) + stat->information |= XSTAT_INFO_FABRICATED; + else + stat->information |= XSTAT_INFO_REMOTE; + + stat->information |= + XSTAT_INFO_NONSYSTEM_OWNERSHIP | XSTAT_INFO_HAS_ACL; return 0; } diff --git a/fs/afs/super.c b/fs/afs/super.c index f02b31e..1f13b48 100644 --- a/fs/afs/super.c +++ b/fs/afs/super.c @@ -314,6 +314,13 @@ static int afs_fill_super(struct super_block *sb, sb->s_bdi = &as->volume->bdi; strlcpy(sb->s_id, as->volume->vlocation->vldb.name, sizeof(sb->s_id)); + /* construct a volume ID from the AFS volume ID and type */ + sb->s_volume_id[4] = as->volume->type; + sb->s_volume_id[3] = as->volume->vid >> 0; + sb->s_volume_id[2] = as->volume->vid >> 8; + sb->s_volume_id[1] = as->volume->vid >> 16; + sb->s_volume_id[0] = as->volume->vid >> 24; + /* allocate the root inode and dentry */ fid.vid = as->volume->vid; fid.vnode = 1;

April 19, 2012

[PATCH 2/6] xstat: Ext4: Return extended attributes

by David Howells

Return extended attributes from the Ext4 filesystem. This includes the following: (1) The inode creation time (i_crtime) as i_btime. (2) The inode i_generation as i_gen if not the root directory. (3) The inode i_version as st_data_version if a file with I_VERSION set or a directory. (4) FS_xxx_FL flags are returned as for ioctl(FS_IOC_GETFLAGS). Signed-off-by: David Howells <dhowells(a)redhat.com> --- fs/ext4/ext4.h | 2 ++ fs/ext4/file.c | 2 +- fs/ext4/inode.c | 32 +++++++++++++++++++++++++++++--- fs/ext4/namei.c | 2 ++ fs/ext4/super.c | 1 + fs/ext4/symlink.c | 2 ++ 6 files changed, 37 insertions(+), 4 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index ab2594a..81806da 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1899,6 +1899,8 @@ extern int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat); extern void ext4_evict_inode(struct inode *); extern void ext4_clear_inode(struct inode *); +extern int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, + struct kstat *stat); extern int ext4_sync_inode(handle_t *, struct inode *); extern void ext4_dirty_inode(struct inode *, int); extern int ext4_change_inode_journal_flag(struct inode *, int); diff --git a/fs/ext4/file.c b/fs/ext4/file.c index cb70f18..ae8654c 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -249,7 +249,7 @@ const struct file_operations ext4_file_operations = { const struct inode_operations ext4_file_inode_operations = { .setattr = ext4_setattr, - .getattr = ext4_getattr, + .getattr = ext4_file_getattr, #ifdef CONFIG_EXT4_FS_XATTR .setxattr = generic_setxattr, .getxattr = generic_getxattr, diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index c77b0bd..eafc188 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -4191,11 +4191,37 @@ err_out: int ext4_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) { - struct inode *inode; - unsigned long delalloc_blocks; + struct inode *inode = dentry->d_inode; + struct ext4_inode_info *ei = EXT4_I(inode); + + stat->result_mask |= XSTAT_BTIME; + stat->btime.tv_sec = ei->i_crtime.tv_sec; + stat->btime.tv_nsec = ei->i_crtime.tv_nsec; + + if (inode->i_ino != EXT4_ROOT_INO) { + stat->result_mask |= XSTAT_GEN; + stat->gen = inode->i_generation; + } + if (S_ISDIR(inode->i_mode) || IS_I_VERSION(inode)) { + stat->result_mask |= XSTAT_VERSION; + stat->version = inode->i_version; + } + + ext4_get_inode_flags(ei); + stat->ioc_flags |= ei->i_flags & EXT4_FL_USER_VISIBLE; + stat->result_mask |= XSTAT_IOC_FLAGS; - inode = dentry->d_inode; generic_fillattr(inode, stat); + return 0; +} + +int ext4_file_getattr(struct vfsmount *mnt, struct dentry *dentry, + struct kstat *stat) +{ + struct inode *inode = dentry->d_inode; + u64 delalloc_blocks; + + ext4_getattr(mnt, dentry, stat); /* * We can't update i_blocks if the block allocation is delayed diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index 349d7b3..6162387 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -2579,6 +2579,7 @@ const struct inode_operations ext4_dir_inode_operations = { .mknod = ext4_mknod, .rename = ext4_rename, .setattr = ext4_setattr, + .getattr = ext4_getattr, #ifdef CONFIG_EXT4_FS_XATTR .setxattr = generic_setxattr, .getxattr = generic_getxattr, @@ -2591,6 +2592,7 @@ const struct inode_operations ext4_dir_inode_operations = { const struct inode_operations ext4_special_inode_operations = { .setattr = ext4_setattr, + .getattr = ext4_getattr, #ifdef CONFIG_EXT4_FS_XATTR .setxattr = generic_setxattr, .getxattr = generic_getxattr, diff --git a/fs/ext4/super.c b/fs/ext4/super.c index ceebaf8..2d395bf 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -3040,6 +3040,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) if (sb->s_magic != EXT4_SUPER_MAGIC) goto cantfind_ext4; sbi->s_kbytes_written = le64_to_cpu(es->s_kbytes_written); + memcpy(sb->s_volume_id, es->s_uuid, sizeof(sb->s_volume_id)); /* Set defaults before we parse the mount options */ def_mount_opts = le32_to_cpu(es->s_default_mount_opts); diff --git a/fs/ext4/symlink.c b/fs/ext4/symlink.c index ed9354a..d8fe7fb 100644 --- a/fs/ext4/symlink.c +++ b/fs/ext4/symlink.c @@ -35,6 +35,7 @@ const struct inode_operations ext4_symlink_inode_operations = { .follow_link = page_follow_link_light, .put_link = page_put_link, .setattr = ext4_setattr, + .getattr = ext4_getattr, #ifdef CONFIG_EXT4_FS_XATTR .setxattr = generic_setxattr, .getxattr = generic_getxattr, @@ -47,6 +48,7 @@ const struct inode_operations ext4_fast_symlink_inode_operations = { .readlink = generic_readlink, .follow_link = ext4_follow_link, .setattr = ext4_setattr, + .getattr = ext4_getattr, #ifdef CONFIG_EXT4_FS_XATTR .setxattr = generic_setxattr, .getxattr = generic_getxattr,

April 19, 2012

[PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by David Howells

Add a pair of system calls to make extended file stats available, including file creation time, inode version and data version where available through the underlying filesystem. The idea was initially proposed as a set of xattrs that could be retrieved with getxattr(), but the general preferance proved to be for new syscalls with an extended stat structure. This has a number of uses: (1) Creation time: The SMB protocol carries the creation time, which could be exported by Samba, which will in turn help CIFS make use of FS-Cache as that can be used for coherency data. This is also specified in NFSv4 as a recommended attribute and could be exported by NFSD [Steve French]. (2) Lightweight stat: Ask for just those details of interest, and allow a netfs (such as NFS) to approximate anything not of interest, possibly without going to the server [Trond Myklebust, Ulrich Drepper]. (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its cached attributes are up to date [Trond Myklebust]. (4) Inode generation number: Useful for FUSE and userspace NFS servers [Bernd Schubert]. (5) Data version number: Could be used by userspace NFS servers [Aneesh Kumar]. Can also be used to modify fill_post_wcc() in NFSD which retrieves i_version directly, but has just called vfs_getattr(). It could get it from the kstat struct if it used vfs_xgetattr() instead. (6) BSD stat compatibility: Including more fields from the BSD stat such as creation time (st_btime) and inode generation number (st_gen) [Jeremy Allison, Bernd Schubert]. (7) Extra coherency data may be useful in making backups [Andreas Dilger]. (8) Allow the filesystem to indicate what it can/cannot provide: A filesystem can now say it doesn't support a standard stat feature if that isn't available, so if, for instance, inode numbers or UIDs don't exist... (9) Make the fields a consistent size on all arches and make them large. (10) Store a 16-byte volume ID in the superblock that can be returned in struct xstat [Steve French]. (11) Include granularity fields in the time data to indicate the granularity of each of the times (NFSv4 time_delta) [Steve French]. (12) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags. (13) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer, Michael Kerrisk]. (14) Spare space, request flags and information flags are provided for future expansion. The following structures are defined for the use of these new system calls: struct xstat_dev { uint32_t major, minor; }; struct xstat_time { uint64_t tv_sec; uint32_t tv_nsec; uint32_t tv_granularity; }; struct xstat { uint32_t st_mask; uint32_t st_mode; uint32_t st_nlink; uint32_t st_uid; uint32_t st_gid; uint32_t st_information; uint32_t st_ioc_flags; uint32_t st_blksize; struct xstat_dev st_rdev; struct xstat_dev st_dev; struct xstat_time st_atime; struct xstat_time st_btime; struct xstat_time st_ctime; struct xstat_time st_mtime; uint64_t st_ino; uint64_t st_size; uint64_t st_blocks; uint64_t st_gen; uint64_t st_version; uint8_t st_volume_id[16]; uint64_t __spares[11]; }; where st_information is local system information about the file, st_btime is the file creation time, st_gen is the inode generation (i_generation), st_data_version is the data version number (i_version), st_ioc_flags is the flags from FS_IOC_GETFLAGS, st_volume_id is where the volume identified is stored, st_result_mask is a bitmask indicating the data provided and __spares[] are where as-yet undefined fields can be placed. The defined bits in request_mask and st_mask are: XSTAT_MODE Want/got st_mode XSTAT_NLINK Want/got st_nlink XSTAT_UID Want/got st_uid XSTAT_GID Want/got st_gid XSTAT_RDEV Want/got st_rdev XSTAT_ATIME Want/got st_atime XSTAT_MTIME Want/got st_mtime XSTAT_CTIME Want/got st_ctime XSTAT_INO Want/got st_ino XSTAT_SIZE Want/got st_size XSTAT_BLOCKS Want/got st_blocks XSTAT_BASIC_STATS [The stuff in the normal stat struct] XSTAT_IOC_FLAGS Want/got FS_IOC_GETFLAGS XSTAT_BTIME Want/got st_btime XSTAT_GEN Want/got st_gen XSTAT_VERSION Want/got st_data_version XSTAT_VOLUME_ID Want/got st_volume_id XSTAT_ALL_STATS [All currently available stuff] The defined bits in st_ioc_flags are the usual FS_xxx_FL, plus some extra flags that might be supplied by the filesystem. Note that Ext4 returns flags outside of {EXT4,FS}_FL_USER_VISIBLE in response to FS_IOC_GETFLAGS. Should {EXT4,FS}_FL_USER_VISIBLE be extended to cover them? Or should the extra flags be suppressed? The defined bits in the st_information field give local system data on a file, how it is accessed, where it is and what it does: XSTAT_INFO_ENCRYPTED File is encrypted XSTAT_INFO_TEMPORARY File is temporary (NTFS/CIFS/deleted) XSTAT_INFO_FABRICATED File was made up by filesystem XSTAT_INFO_KERNEL_API File is kernel API (eg: procfs/sysfs) XSTAT_INFO_REMOTE File is remote XSTAT_INFO_OFFLINE File is offline (CIFS) XSTAT_INFO_AUTOMOUNT Dir is automount trigger XSTAT_INFO_AUTODIR Dir provides unlisted automounts XSTAT_INFO_NONSYSTEM_OWNERSHIP File has non-system ownership details XSTAT_INFO_HAS_ACL File has an ACL of some sort XSTAT_INFO_REPARSE_POINT File is reparse point (NTFS/CIFS) XSTAT_INFO_HIDDEN File is marked hidden (DOS+) XSTAT_INFO_SYSTEM File is marked system (DOS+) XSTAT_INFO_ARCHIVE File is marked archive (DOS+) These are for the use of GUI tools that might want to mark files specially, depending on what they are. I've tried not to provide overlap with st_ioc_flags where something usable exists there. Should Hidden, System and Archive flags be associated with ioc_flags, perhaps with ioc_flags extended to 64-bits? The system calls are: ssize_t ret = xstat(int dfd, const char *filename, unsigned int flags, unsigned int mask, struct xstat *buffer); ssize_t ret = fxstat(unsigned fd, unsigned int flags, unsigned int mask, struct xstat *buffer); The dfd, filename, flags and fd parameters indicate the file to query. There is no equivalent of lstat() as that can be emulated with xstat() by passing AT_SYMLINK_NOFOLLOW in flags. AT_FORCE_ATTR_SYNC can also be set in flags. This will require a network filesystem to synchronise its attributes with the server. mask is a bitmask indicating the fields in struct xstat that are of interest to the caller. The user should set this to XSTAT__BASIC_STATS to get the basic set returned by stat(). Should there just be one xstat() syscall that does fxstat() if filename is NULL? The fields in struct xstat come in a number of classes: (0) st_dev, st_blksize, st_information. These are local data and are always available. (1) st_mode, st_nlinks, st_uid, st_gid, st_[amc]time, st_ino, st_size, st_blocks. These will be returned whether the caller asks for them or not. The corresponding bits in result_mask will be set to indicate their presence. If the caller didn't ask for them, then they may be approximated. For example, NFS won't waste any time updating them from the server, unless as a byproduct of updating something requested. If the values don't actually exist for the underlying object (such as UID or GID on a DOS file), then the bit won't be set in the result_mask, even if the caller asked for the value and the returned value will be a fabrication. (2) st_rdev. As for class (1), but this won't be returned if the file is not a blockdev or chardev. The bit will be cleared if the value is not returned. (3) File creation time (st_btime), inode generation (st_gen), data version (st_version), volume_id (st_volume_id) and inode flags (st_ioc_flags). These will be returned if available whether the caller asked for them or not. The corresponding bits in result_mask will be set or cleared as appropriate to indicate their presence. If the caller didn't ask for them, then they may be approximated. For example, NFS won't waste any time updating them from the server, unless as a byproduct of updating something requested. At the moment, this will only work on x86_64 and i386 as it requires system calls to be wired up. ======= TESTING ======= The following test program can be used to test the xstat system call: /* Test the xstat() system call * * Copyright (C) 2010 Red Hat, Inc. All Rights Reserved. * Written by David Howells (dhowells(a)redhat.com) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public Licence * as published by the Free Software Foundation; either version * 2 of the Licence, or (at your option) any later version. */ #define _GNU_SOURCE #define _ATFILE_SOURCE #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <fcntl.h> #include <time.h> #include <sys/syscall.h> #include <sys/stat.h> #include <sys/types.h> #define AT_NO_AUTOMOUNT 0x800 #define AT_FORCE_ATTR_SYNC 0x2000 #define XSTAT_MODE 0x00000001U #define XSTAT_NLINK 0x00000002U #define XSTAT_UID 0x00000004U #define XSTAT_GID 0x00000008U #define XSTAT_RDEV 0x00000010U #define XSTAT_ATIME 0x00000020U #define XSTAT_MTIME 0x00000040U #define XSTAT_CTIME 0x00000080U #define XSTAT_INO 0x00000100U #define XSTAT_SIZE 0x00000200U #define XSTAT_BLOCKS 0x00000400U #define XSTAT_BASIC_STATS 0x000007ffU #define XSTAT_BTIME 0x00000800U #define XSTAT_GEN 0x00001000U #define XSTAT_VERSION 0x00002000U #define XSTAT_IOC_FLAGS 0x00004000U #define XSTAT_VOLUME_ID 0x00008000U #define XSTAT_ALL_STATS 0x0000ffffU struct xstat_dev { uint32_t major; uint32_t minor; }; struct xstat_time { uint64_t tv_sec; uint32_t tv_nsec; uint32_t tv_granularity; }; struct xstat { uint32_t st_mask; uint32_t st_mode; uint32_t st_nlink; uint32_t st_uid; uint32_t st_gid; uint32_t st_information; uint32_t st_ioc_flags; uint32_t st_blksize; struct xstat_dev st_rdev; struct xstat_dev st_dev; struct xstat_time st_atim; struct xstat_time st_btim; struct xstat_time st_ctim; struct xstat_time st_mtim; uint64_t st_ino; uint64_t st_size; uint64_t st_blksize; uint64_t st_blocks; uint64_t st_gen; uint64_t st_version; uint64_t st_volume_id[16]; uint64_t st_spares[11]; }; #define XSTAT_INFO_ENCRYPTED 0x00000001U #define XSTAT_INFO_TEMPORARY 0x00000002U #define XSTAT_INFO_FABRICATED 0x00000004U #define XSTAT_INFO_KERNEL_API 0x00000008U #define XSTAT_INFO_REMOTE 0x00000010U #define XSTAT_INFO_OFFLINE 0x00000020U #define XSTAT_INFO_AUTOMOUNT 0x00000040U #define XSTAT_INFO_AUTODIR 0x00000080U #define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U #define XSTAT_INFO_HAS_ACL 0x00000200U #define XSTAT_INFO_REPARSE_POINT 0x00000400U #define XSTAT_INFO_HIDDEN 0x00000800U #define XSTAT_INFO_SYSTEM 0x00001000U #define XSTAT_INFO_ARCHIVE 0x00002000U #define __NR_xstat 312 #define __NR_fxstat 313 static __attribute__((unused)) ssize_t xstat(int dfd, const char *filename, unsigned flags, unsigned int mask, struct xstat *buffer) { return syscall(__NR_xstat, dfd, filename, flags, mask, buffer); } static __attribute__((unused)) ssize_t fxstat(int fd, unsigned flags, unsigned int mask, struct xstat *buffer) { return syscall(__NR_fxstat, fd, flags, mask, buffer); } static void print_time(const char *field, const struct xstat_time *xstm) { struct tm tm; time_t tim; char buffer[100]; int len; tim = xstm->tv_sec; if (!localtime_r(&tim, &tm)) { perror("localtime_r"); exit(1); } len = strftime(buffer, 100, "%F %T", &tm); if (len == 0) { perror("strftime"); exit(1); } printf("%s", field); fwrite(buffer, 1, len, stdout); printf(".%09u", xstm->tv_nsec); len = strftime(buffer, 100, "%z", &tm); if (len == 0) { perror("strftime2"); exit(1); } fwrite(buffer, 1, len, stdout); printf("\n"); } static void dump_xstat(struct xstat *xst) { char buffer[256], ft; printf("results=%x\n", xst->st_mask); printf(" "); if (xst->st_mask & XSTAT_SIZE) printf(" Size: %-15llu", (unsigned long long) xst->st_size); if (xst->st_mask & XSTAT_BLOCKS) printf(" Blocks: %-10llu", (unsigned long long) xst->st_blocks); printf(" IO Block: %-6llu ", (unsigned long long) xst->st_blksize); if (xst->st_mask & XSTAT_MODE) { switch (xst->st_mode & S_IFMT) { case S_IFIFO: printf(" FIFO\n"); ft = 'p'; break; case S_IFCHR: printf(" character special file\n"); ft = 'c'; break; case S_IFDIR: printf(" directory\n"); ft = 'd'; break; case S_IFBLK: printf(" block special file\n"); ft = 'b'; break; case S_IFREG: printf(" regular file\n"); ft = '-'; break; case S_IFLNK: printf(" symbolic link\n"); ft = 'l'; break; case S_IFSOCK: printf(" socket\n"); ft = 's'; break; default: printf("unknown type (%o)\n", xst->st_mode & S_IFMT); ft = '?'; break; } } sprintf(buffer, "%02x:%02x", xst->st_dev.major, xst->st_dev.minor); printf("Device: %-15s", buffer); if (xst->st_mask & XSTAT_INO) printf(" Inode: %-11llu", (unsigned long long) xst->st_ino); if (xst->st_mask & XSTAT_SIZE) printf(" Links: %-5u", xst->st_nlink); if (xst->st_mask & XSTAT_RDEV) printf(" Device type: %u,%u", xst->st_rdev.major, xst->st_rdev.minor); printf("\n"); if (xst->st_mask & XSTAT_MODE) printf("Access: (%04o/%c%c%c%c%c%c%c%c%c%c) ", xst->st_mode & 07777, ft, xst->st_mode & S_IRUSR ? 'r' : '-', xst->st_mode & S_IWUSR ? 'w' : '-', xst->st_mode & S_IXUSR ? 'x' : '-', xst->st_mode & S_IRGRP ? 'r' : '-', xst->st_mode & S_IWGRP ? 'w' : '-', xst->st_mode & S_IXGRP ? 'x' : '-', xst->st_mode & S_IROTH ? 'r' : '-', xst->st_mode & S_IWOTH ? 'w' : '-', xst->st_mode & S_IXOTH ? 'x' : '-'); if (xst->st_mask & XSTAT_UID) printf("Uid: %d \n", xst->st_uid); if (xst->st_mask & XSTAT_GID) printf("Gid: %u\n", xst->st_gid); if (xst->st_mask & XSTAT_ATIME) print_time("Access: ", &xst->st_atim); if (xst->st_mask & XSTAT_MTIME) print_time("Modify: ", &xst->st_mtim); if (xst->st_mask & XSTAT_CTIME) print_time("Change: ", &xst->st_ctim); if (xst->st_mask & XSTAT_BTIME) print_time("Create: ", &xst->st_btim); if (xst->st_mask & XSTAT_GEN) printf("Inode version: %llxh\n", (unsigned long long) xst->st_gen); if (xst->st_mask & XSTAT_VERSION) printf("Data version: %llxh\n", (unsigned long long) xst->st_version); if (xst->st_mask & XSTAT_IOC_FLAGS) { unsigned char bits; int loop, byte; static char flag_representation[32 + 1] = /* FS_IOC_GETFLAGS flags: */ "????????" /* 31-24 0x00000000-ff000000 */ "????ehTD" /* 23-16 0x00000000-00ff0000 */ "tj?IE?XZ" /* 15- 8 0x00000000-0000ff00 */ "AdaiScus" /* 7- 0 0x00000000-000000ff */ ; printf("Inode flags: %08x (", xst->st_ioc_flags); for (byte = 32 - 8; byte >= 0; byte -= 8) { bits = xst->st_ioc_flags >> byte; for (loop = 7; loop >= 0; loop--) { int bit = byte + loop; if (bits & 0x80) putchar(flag_representation[31 - bit]); else putchar('-'); bits <<= 1; } if (byte) putchar(' '); } printf(")\n"); } if (xst->st_information) { unsigned char bits; int loop, byte; static char info_representation[32 + 1] = /* XSTAT_INFO_ flags: */ "????????" /* 31-24 0x00000000-ff000000 */ "????????" /* 23-16 0x00000000-00ff0000 */ "??ASHRan" /* 15- 8 0x00000000-0000ff00 */ "dmorkfte" /* 7- 0 0x00000000-000000ff */ ; printf("Information: %08x (", xst->st_information); for (byte = 32 - 8; byte >= 0; byte -= 8) { bits = xst->st_information >> byte; for (loop = 7; loop >= 0; loop--) { int bit = byte + loop; if (bits & 0x80) putchar(info_representation[31 - bit]); else putchar('-'); bits <<= 1; } if (byte) putchar(' '); } printf(")\n"); } if (xst->st_mask & XSTAT_VOLUME_ID) { int loop; printf("Volume ID: "); for (loop = 0; loop < sizeof(xst->st_volume_id); loop++) { printf("%02x", xst->st_volume_id[loop]); if (loop == 7) printf("-"); } printf("\n"); } } void dump_hex(unsigned long long *data, int from, int to) { unsigned offset, print_offset = 1, col = 0; from /= 8; to = (to + 7) / 8; for (offset = from; offset < to; offset++) { if (print_offset) { printf("%04x: ", offset * 8); print_offset = 0; } printf("%016llx", data[offset]); col++; if ((col & 3) == 0) { printf("\n"); print_offset = 1; } else { printf(" "); } } if (!print_offset) printf("\n"); } int main(int argc, char **argv) { struct xstat xst; int ret, raw = 0, atflag = AT_SYMLINK_NOFOLLOW; unsigned int mask = XSTAT_ALL_STATS; for (argv++; *argv; argv++) { if (strcmp(*argv, "-F") == 0) { atflag |= AT_FORCE_ATTR_SYNC; continue; } if (strcmp(*argv, "-L") == 0) { atflag &= ~AT_SYMLINK_NOFOLLOW; continue; } if (strcmp(*argv, "-O") == 0) { mask &= ~XSTAT_BASIC_STATS; continue; } if (strcmp(*argv, "-A") == 0) { atflag |= AT_NO_AUTOMOUNT; continue; } if (strcmp(*argv, "-R") == 0) { raw = 1; continue; } memset(&xst, 0xbf, sizeof(xst)); ret = xstat(AT_FDCWD, *argv, atflag, mask, &xst); printf("xstat(%s) = %d\n", *argv, ret); if (ret < 0) { perror(*argv); exit(1); } if (raw) dump_hex((unsigned long long *)&xst, 0, sizeof(xst)); dump_xstat(&xst); } return 0; } Just compile and run, passing it paths to the files you want to examine: [root(a)andromeda ~]# /tmp/xstat /proc/$$ xstat(/proc/2074) = 160 results=47ef Size: 0 Blocks: 0 IO Block: 1024 directory Device: 00:03 Inode: 9072 Links: 7 Access: (0555/dr-xr-xr-x) Uid: 0 Gid: 0 Access: 2010-07-14 16:50:46.609336272+0100 Modify: 2010-07-14 16:50:46.609336272+0100 Change: 2010-07-14 16:50:46.609336272+0100 Inode flags: 0000000100000000 (-------- -------- -------- -------S -------- -------- -------- --------) [root(a)andromeda ~]# /tmp/xstat /afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm xstat(/afs/archive/linuxdev/fedora9/x86_64/kernel-devel-2.6.25.10-86.fc9.x86_64.rpm) = 160 results=77ef Size: 5413882 Blocks: 0 IO Block: 4096 regular file Device: 00:15 Inode: 2288 Links: 1 Access: (0644/-rw-r--r--) Uid: 75338 Gid: 0 Access: 2008-11-05 19:47:22.000000000+0000 Modify: 2008-11-05 19:47:22.000000000+0000 Change: 2008-11-05 19:47:22.000000000+0000 Inode version: 795h Data version: 2h Inode flags: 0000000800000000 (-------- -------- -------- ----r--- -------- -------- -------- --------) Signed-off-by: David Howells <dhowells(a)redhat.com> --- arch/x86/syscalls/syscall_32.tbl | 2 arch/x86/syscalls/syscall_64.tbl | 2 fs/stat.c | 350 +++++++++++++++++++++++++++++++++++--- include/linux/fcntl.h | 1 include/linux/fs.h | 4 include/linux/stat.h | 126 +++++++++++++- include/linux/syscalls.h | 7 + 7 files changed, 461 insertions(+), 31 deletions(-) diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl index 29f9f05..980eb5a 100644 --- a/arch/x86/syscalls/syscall_32.tbl +++ b/arch/x86/syscalls/syscall_32.tbl @@ -355,3 +355,5 @@ 346 i386 setns sys_setns 347 i386 process_vm_readv sys_process_vm_readv compat_sys_process_vm_readv 348 i386 process_vm_writev sys_process_vm_writev compat_sys_process_vm_writev +349 i386 xstat sys_xstat +350 i386 fxstat sys_fxstat diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl index dd29a9e..7ae24bb 100644 --- a/arch/x86/syscalls/syscall_64.tbl +++ b/arch/x86/syscalls/syscall_64.tbl @@ -318,6 +318,8 @@ 309 common getcpu sys_getcpu 310 64 process_vm_readv sys_process_vm_readv 311 64 process_vm_writev sys_process_vm_writev +312 common xstat sys_xstat +313 common fxstat sys_fxstat # # x32-specific system call numbers start at 512 to avoid cache impact # for native 64-bit operation. diff --git a/fs/stat.c b/fs/stat.c index c733dc5..af3ef33 100644 --- a/fs/stat.c +++ b/fs/stat.c @@ -18,8 +18,20 @@ #include <asm/uaccess.h> #include <asm/unistd.h> +/** + * generic_fillattr - Fill in the basic attributes from the inode struct + * @inode: Inode to use as the source + * @stat: Where to fill in the attributes + * + * Fill in the basic attributes in the kstat structure from data that's to be + * found on the VFS inode structure. This is the default if no getattr inode + * operation is supplied. + */ void generic_fillattr(struct inode *inode, struct kstat *stat) { + struct super_block *sb = inode->i_sb; + u32 x; + stat->dev = inode->i_sb->s_dev; stat->ino = inode->i_ino; stat->mode = inode->i_mode; @@ -27,17 +39,61 @@ void generic_fillattr(struct inode *inode, struct kstat *stat) stat->uid = inode->i_uid; stat->gid = inode->i_gid; stat->rdev = inode->i_rdev; - stat->size = i_size_read(inode); - stat->atime = inode->i_atime; stat->mtime = inode->i_mtime; stat->ctime = inode->i_ctime; - stat->blksize = (1 << inode->i_blkbits); + stat->size = i_size_read(inode); stat->blocks = inode->i_blocks; -} + stat->blksize = (1 << inode->i_blkbits); + stat->result_mask |= XSTAT_BASIC_STATS & ~XSTAT_RDEV; + if (IS_NOATIME(inode)) + stat->result_mask &= ~XSTAT_ATIME; + else + stat->atime = inode->i_atime; + + if (S_ISREG(stat->mode) && stat->nlink == 0) + stat->information |= XSTAT_INFO_TEMPORARY; + if (IS_AUTOMOUNT(inode)) + stat->information |= XSTAT_INFO_AUTOMOUNT; + if (IS_POSIXACL(inode)) + stat->information |= XSTAT_INFO_HAS_ACL; + + /* if unset, assume 1s granularity */ + stat->tv_granularity = sb->s_time_gran ?: 1000000000U; + + if (unlikely(S_ISBLK(stat->mode) || S_ISCHR(stat->mode))) + stat->result_mask |= XSTAT_RDEV; + + x = ((u32*)&stat->volume_id)[0] = ((u32*)&sb->s_volume_id)[0]; + x |= ((u32*)&stat->volume_id)[1] = ((u32*)&sb->s_volume_id)[1]; + x |= ((u32*)&stat->volume_id)[2] = ((u32*)&sb->s_volume_id)[2]; + x |= ((u32*)&stat->volume_id)[3] = ((u32*)&sb->s_volume_id)[3]; + if (x) + stat->result_mask |= XSTAT_VOLUME_ID; +} EXPORT_SYMBOL(generic_fillattr); -int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) +/** + * vfs_xgetattr - Get the basic and extra attributes of a file + * @mnt: The mountpoint to which the dentry belongs + * @dentry: The file of interest + * @stat: Where to return the statistics + * + * Ask the filesystem for a file's attributes. The caller must have preset + * stat->request_mask and stat->query_flags to indicate what they want. + * + * If the file is remote, the filesystem can be forced to update the attributes + * from the backing store by passing AT_FORCE_ATTR_SYNC in query_flags. + * + * Bits must have been set in stat->request_mask to indicate which attributes + * the caller wants retrieving. Any such attribute not requested may be + * returned anyway, but the value may be approximate, and, if remote, may not + * have been synchronised with the server. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_xgetattr(struct vfsmount *mnt, struct dentry *dentry, + struct kstat *stat) { struct inode *inode = dentry->d_inode; int retval; @@ -46,64 +102,184 @@ int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) if (retval) return retval; + stat->result_mask = 0; + stat->information = 0; + stat->ioc_flags = 0; if (inode->i_op->getattr) return inode->i_op->getattr(mnt, dentry, stat); generic_fillattr(inode, stat); return 0; } +EXPORT_SYMBOL(vfs_xgetattr); +/** + * vfs_getattr - Get the basic attributes of a file + * @mnt: The mountpoint to which the dentry belongs + * @dentry: The file of interest + * @stat: Where to return the statistics + * + * Ask the filesystem for a file's attributes. If remote, the filesystem isn't + * forced to update its files from the backing store. Only the basic set of + * attributes will be retrieved; anyone wanting more must use vfs_getxattr(), + * as must anyone who wants to force attributes to be sync'd with the server. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat) +{ + stat->query_flags = 0; + stat->request_mask = XSTAT_BASIC_STATS; + return vfs_xgetattr(mnt, dentry, stat); +} EXPORT_SYMBOL(vfs_getattr); -int vfs_fstat(unsigned int fd, struct kstat *stat) +/** + * vfs_fxstat - Get basic and extra attributes by file descriptor + * @fd: The file descriptor refering to the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xgetattr(). The main difference is + * that it uses a file descriptor to determine the file location. + * + * The caller must have preset stat->query_flags and stat->request_mask as for + * vfs_xgetattr(). + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_fxstat(unsigned int fd, struct kstat *stat) { struct file *f = fget(fd); int error = -EBADF; + if (stat->query_flags & ~KSTAT_QUERY_FLAGS) + return -EINVAL; if (f) { - error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat); + error = vfs_xgetattr(f->f_path.mnt, f->f_path.dentry, stat); fput(f); } return error; } +EXPORT_SYMBOL(vfs_fxstat); + +/** + * vfs_fstat - Get basic attributes by file descriptor + * @fd: The file descriptor refering to the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_getattr(). The main difference is + * that it uses a file descriptor to determine the file location. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_fstat(unsigned int fd, struct kstat *stat) +{ + stat->query_flags = 0; + stat->request_mask = XSTAT_BASIC_STATS; + return vfs_fxstat(fd, stat); +} EXPORT_SYMBOL(vfs_fstat); -int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, - int flag) +/** + * vfs_xstat - Get basic and extra attributes by filename + * @dfd: A file descriptor representing the base dir for a relative filename + * @filename: The name of the file of interest + * @flags: Flags to control the query + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xgetattr(). The main difference is + * that it uses a filename and base directory to determine the file location. + * Additionally, the addition of AT_SYMLINK_NOFOLLOW to flags will prevent a + * symlink at the given name from being referenced. + * + * The caller must have preset stat->request_mask as for vfs_xgetattr(). The + * flags are also used to load up stat->query_flags. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_xstat(int dfd, const char __user *filename, int flags, + struct kstat *stat) { struct path path; - int error = -EINVAL; - int lookup_flags = 0; + int error, lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT; - if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | - AT_EMPTY_PATH)) != 0) - goto out; + if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT | + AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0) + return -EINVAL; - if (!(flag & AT_SYMLINK_NOFOLLOW)) - lookup_flags |= LOOKUP_FOLLOW; - if (flag & AT_EMPTY_PATH) + if (flags & AT_SYMLINK_NOFOLLOW) + lookup_flags &= ~LOOKUP_FOLLOW; + if (flags & AT_NO_AUTOMOUNT) + lookup_flags &= ~LOOKUP_AUTOMOUNT; + if (flags & AT_EMPTY_PATH) lookup_flags |= LOOKUP_EMPTY; + stat->query_flags = flags & KSTAT_QUERY_FLAGS; error = user_path_at(dfd, filename, lookup_flags, &path); - if (error) - goto out; - - error = vfs_getattr(path.mnt, path.dentry, stat); - path_put(&path); -out: + if (!error) { + error = vfs_xgetattr(path.mnt, path.dentry, stat); + path_put(&path); + } return error; } +EXPORT_SYMBOL(vfs_xstat); + +/** + * vfs_fstatat - Get basic attributes by filename + * @dfd: A file descriptor representing the base dir for a relative filename + * @filename: The name of the file of interest + * @flags: Flags to control the query + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xstat(). The difference is that it + * preselects basic stats only. The flags are used to load up + * stat->query_flags in addition to indicating symlink handling during path + * resolution. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat, + int flags) +{ + stat->request_mask = XSTAT_BASIC_STATS; + return vfs_xstat(dfd, filename, flags, stat); +} EXPORT_SYMBOL(vfs_fstatat); -int vfs_stat(const char __user *name, struct kstat *stat) +/** + * vfs_stat - Get basic attributes by filename + * @filename: The name of the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xstat(). The difference is that it + * preselects basic stats only, terminal symlinks are followed regardless and a + * remote filesystem can't be forced to query the server. If such is desired, + * vfs_xstat() should be used instead. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ +int vfs_stat(const char __user *filename, struct kstat *stat) { - return vfs_fstatat(AT_FDCWD, name, stat, 0); + stat->request_mask = XSTAT_BASIC_STATS; + return vfs_xstat(AT_FDCWD, filename, 0, stat); } EXPORT_SYMBOL(vfs_stat); +/** + * vfs_stat - Get basic attributes by filename, without following terminal symlink + * @filename: The name of the file of interest + * @stat: The result structure to fill in. + * + * This function is a wrapper around vfs_xstat(). The difference is that it + * preselects basic stats only, terminal symlinks are note followed regardless + * and a remote filesystem can't be forced to query the server. If such is + * desired, vfs_xstat() should be used instead. + * + * 0 will be returned on success, and a -ve error code if unsuccessful. + */ int vfs_lstat(const char __user *name, struct kstat *stat) { - return vfs_fstatat(AT_FDCWD, name, stat, AT_SYMLINK_NOFOLLOW); + return vfs_xstat(AT_FDCWD, name, AT_SYMLINK_NOFOLLOW, stat); } EXPORT_SYMBOL(vfs_lstat); @@ -118,7 +294,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta { static int warncount = 5; struct __old_kernel_stat tmp; - + if (warncount > 0) { warncount--; printk(KERN_WARNING "VFS: Warning: %s using old stat() call. Recompile your binary.\n", @@ -143,7 +319,7 @@ static int cp_old_stat(struct kstat *stat, struct __old_kernel_stat __user * sta #if BITS_PER_LONG == 32 if (stat->size > MAX_NON_LFS) return -EOVERFLOW; -#endif +#endif tmp.st_size = stat->size; tmp.st_atime = stat->atime.tv_sec; tmp.st_mtime = stat->mtime.tv_sec; @@ -225,7 +401,7 @@ static int cp_new_stat(struct kstat *stat, struct stat __user *statbuf) #if BITS_PER_LONG == 32 if (stat->size > MAX_NON_LFS) return -EOVERFLOW; -#endif +#endif tmp.st_size = stat->size; tmp.st_atime = stat->atime.tv_sec; tmp.st_mtime = stat->mtime.tv_sec; @@ -412,6 +588,122 @@ SYSCALL_DEFINE4(fstatat64, int, dfd, const char __user *, filename, } #endif /* __ARCH_WANT_STAT64 */ +/* + * Get the xstat parameters if supplied + */ +static int xstat_get_params(unsigned int mask, struct xstat __user *buffer, + struct kstat *stat) +{ + memset(stat, 0xde, sizeof(*stat)); // DEBUGGING + + if (!access_ok(VERIFY_WRITE, buffer, sizeof(*buffer))) + return -EFAULT; + + stat->request_mask = mask & XSTAT_ALL_STATS; + stat->result_mask = 0; + return 0; +} + +/* + * Set the xstat results. + * + * If the buffer size was 0, we just return the size of the buffer needed to + * return the full result. + * + * If bufsize indicates a buffer of insufficient size to hold the full result, + * we return -E2BIG. + * + * Otherwise we copy the extended stats to userspace and return the amount of + * data written into the buffer (or -EFAULT). + */ +static long xstat_set_result(struct kstat *stat, struct xstat __user *buffer) +{ + u32 mask = stat->result_mask, gran = stat->tv_granularity; + +#define __put_timestamp(kts, uts) ( \ + __put_user(kts.tv_sec, uts.tv_sec ) || \ + __put_user(kts.tv_nsec, uts.tv_nsec ) || \ + __put_user(gran, uts.tv_granularity )) + + /* clear out anything we're not returning */ + if (!(mask & XSTAT_IOC_FLAGS)) + stat->ioc_flags = 0; + if (!(mask & XSTAT_BTIME)) + memset(&stat->btime, 0, sizeof(stat->btime)); + if (!(mask & XSTAT_GEN)) + stat->gen = 0; + if (!(mask & XSTAT_VERSION)) + stat->version = 0; + if (!(mask & XSTAT_VOLUME_ID)) + memset(&stat->volume_id, 0, sizeof(stat->volume_id)); + + /* transfer the results */ + if (__put_user(mask, &buffer->st_mask ) || + __put_user(stat->mode, &buffer->st_mode ) || + __put_user(stat->nlink, &buffer->st_nlink ) || + __put_user(stat->uid, &buffer->st_uid ) || + __put_user(stat->gid, &buffer->st_gid ) || + __put_user(stat->information, &buffer->st_information ) || + __put_user(stat->ioc_flags, &buffer->st_ioc_flags ) || + __put_user(stat->blksize, &buffer->st_blksize ) || + __put_user(MAJOR(stat->rdev), &buffer->st_rdev.major ) || + __put_user(MINOR(stat->rdev), &buffer->st_rdev.minor ) || + __put_user(MAJOR(stat->dev), &buffer->st_dev.major ) || + __put_user(MINOR(stat->dev), &buffer->st_dev.minor ) || + __put_timestamp(stat->atime, &buffer->st_atime ) || + __put_timestamp(stat->btime, &buffer->st_btime ) || + __put_timestamp(stat->ctime, &buffer->st_ctime ) || + __put_timestamp(stat->mtime, &buffer->st_mtime ) || + __put_user(stat->ino, &buffer->st_ino ) || + __put_user(stat->size, &buffer->st_size ) || + __put_user(stat->blocks, &buffer->st_blocks ) || + __put_user(stat->gen, &buffer->st_gen ) || + __put_user(stat->version, &buffer->st_version ) || + __copy_to_user(&buffer->st_volume_id, &stat->volume_id, + sizeof(buffer->st_volume_id) ) || + __clear_user(&buffer->__spares, sizeof(buffer->__spares))) + return -EFAULT; + return 0; +} + +/* + * System call to get extended stats by path + */ +SYSCALL_DEFINE5(xstat, + int, dfd, const char __user *, filename, unsigned, flags, + unsigned int, mask, struct xstat __user *, buffer) +{ + struct kstat stat; + int error; + + error = xstat_get_params(mask, buffer, &stat); + if (error != 0) + return error; + error = vfs_xstat(dfd, filename, flags, &stat); + if (error) + return error; + return xstat_set_result(&stat, buffer); +} + +/* + * System call to get extended stats by file descriptor + */ +SYSCALL_DEFINE4(fxstat, unsigned int, fd, unsigned int, flags, + unsigned int, mask, struct xstat __user *, buffer) +{ + struct kstat stat; + int error; + + error = xstat_get_params(mask, buffer, &stat); + if (error < 0) + return error; + stat.query_flags = flags; + error = vfs_fxstat(fd, &stat); + if (error) + return error; + return xstat_set_result(&stat, buffer); +} + /* Caller is here responsible for sufficient locking (ie. inode->i_lock) */ void __inode_add_bytes(struct inode *inode, loff_t bytes) { diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h index f550f89..faa9e5d 100644 --- a/include/linux/fcntl.h +++ b/include/linux/fcntl.h @@ -47,6 +47,7 @@ #define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ #define AT_NO_AUTOMOUNT 0x800 /* Suppress terminal automount traversal */ #define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */ +#define AT_FORCE_ATTR_SYNC 0x2000 /* Force the attributes to be sync'd with the server */ #ifdef __KERNEL__ diff --git a/include/linux/fs.h b/include/linux/fs.h index 8de6755..ec6c62e 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1467,6 +1467,7 @@ struct super_block { char s_id[32]; /* Informational name */ u8 s_uuid[16]; /* UUID */ + unsigned char s_volume_id[16]; /* Volume identifier */ void *s_fs_info; /* Filesystem private info */ unsigned int s_max_links; @@ -2470,6 +2471,7 @@ extern const struct inode_operations page_symlink_inode_operations; extern int generic_readlink(struct dentry *, char __user *, int); extern void generic_fillattr(struct inode *, struct kstat *); extern int vfs_getattr(struct vfsmount *, struct dentry *, struct kstat *); +extern int vfs_xgetattr(struct vfsmount *, struct dentry *, struct kstat *); void __inode_add_bytes(struct inode *inode, loff_t bytes); void inode_add_bytes(struct inode *inode, loff_t bytes); void inode_sub_bytes(struct inode *inode, loff_t bytes); @@ -2482,6 +2484,8 @@ extern int vfs_stat(const char __user *, struct kstat *); extern int vfs_lstat(const char __user *, struct kstat *); extern int vfs_fstat(unsigned int, struct kstat *); extern int vfs_fstatat(int , const char __user *, struct kstat *, int); +extern int vfs_xstat(int, const char __user *, int, struct kstat *); +extern int vfs_xfstat(unsigned int, struct kstat *); extern int do_vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, unsigned long arg); diff --git a/include/linux/stat.h b/include/linux/stat.h index 611c398..0ff561a 100644 --- a/include/linux/stat.h +++ b/include/linux/stat.h @@ -3,6 +3,7 @@ #ifdef __KERNEL__ +#include <linux/types.h> #include <asm/stat.h> #endif @@ -46,6 +47,117 @@ #endif +/* + * Query request/result mask + * + * Bits should be set in request_mask to request particular items when calling + * xstat() or fxstat(). + * + * The bits in st_mask may or may not be set upon return, in part depending on + * what was set in the mask argument: + * + * - if not available at all, the bit will be cleared before returning and the + * field will be cleared; otherwise, + * + * - if AT_FORCE_ATTR_SYNC is set, then the datum will be synchronised to the + * server and the field and bit will be set on return; otherwise, + * + * - if explicitly requested, the datum will be synchronised to a server or + * other medium if out of date before being returned, and the bit will be set + * on return; otherwise, + * + * - if not requested, but available in approximate form without any effort, it + * will be filled in anyway, and the bit will be set upon return (it might + * not be up to date, however, and no attempt will be made to synchronise the + * internal state first); otherwise, + * + * - the field and the bit will be cleared before returning. + * + * Items in XSTAT_BASIC_STATS may be marked unavailable on return, but they + * will have a value installed for compatibility purposes so that stat() and + * co. can be emulated in userspace. + */ +#define XSTAT_MODE 0x00000001U /* want/got st_mode */ +#define XSTAT_NLINK 0x00000002U /* want/got st_nlink */ +#define XSTAT_UID 0x00000004U /* want/got st_uid */ +#define XSTAT_GID 0x00000008U /* want/got st_gid */ +#define XSTAT_RDEV 0x00000010U /* want/got st_rdev */ +#define XSTAT_ATIME 0x00000020U /* want/got st_atime */ +#define XSTAT_MTIME 0x00000040U /* want/got st_mtime */ +#define XSTAT_CTIME 0x00000080U /* want/got st_ctime */ +#define XSTAT_INO 0x00000100U /* want/got st_ino */ +#define XSTAT_SIZE 0x00000200U /* want/got st_size */ +#define XSTAT_BLOCKS 0x00000400U /* want/got st_blocks */ +#define XSTAT_BASIC_STATS 0x000007ffU /* the stuff in the normal stat struct */ +#define XSTAT_IOC_FLAGS 0x00000800U /* want/got FS_IOC_GETFLAGS */ +#define XSTAT_BTIME 0x00001000U /* want/got st_btime */ +#define XSTAT_GEN 0x00002000U /* want/got st_gen */ +#define XSTAT_VERSION 0x00004000U /* want/got st_version */ +#define XSTAT_VOLUME_ID 0x00008000U /* want/got st_volume_id */ +#define XSTAT_ALL_STATS 0x0000ffffU /* all supported stats */ + +/* + * Extended stat structures + */ +struct xstat_dev { + uint32_t major, minor; +}; + +struct xstat_time { + int64_t tv_sec; + uint32_t tv_nsec; + uint32_t tv_granularity; /* time granularity (in nS) */ +}; + +struct xstat { + uint32_t st_mask; /* what results were written */ + uint32_t st_mode; /* file mode */ + uint32_t st_nlink; /* number of hard links */ + uint32_t st_uid; /* user ID of owner */ + uint32_t st_gid; /* group ID of owner */ + uint32_t st_information; /* information about the file */ + uint32_t st_ioc_flags; /* as FS_IOC_GETFLAGS */ + uint32_t st_blksize; /* optimal size for filesystem I/O */ + struct xstat_dev st_rdev; /* device ID of special file */ + struct xstat_dev st_dev; /* ID of device containing file */ + struct xstat_time st_atime; /* last access time */ + struct xstat_time st_btime; /* file creation time */ + struct xstat_time st_ctime; /* last attribute change time */ + struct xstat_time st_mtime; /* last data modification time */ + uint64_t st_ino; /* inode number */ + uint64_t st_size; /* file size */ + uint64_t st_blocks; /* number of 512-byte blocks allocated */ + uint64_t st_gen; /* inode generation number */ + uint64_t st_version; /* data version number */ + uint8_t st_volume_id[16]; /* volume identifier */ + uint64_t __spares[11]; /* spare space for future expansion */ +}; + +/* + * Flags to be found in st_information + * + * These give information about the features or the state of a file that might + * be of use to ordinary userspace programs such as GUIs or ls rather than + * specialised tools. + * + * Additional information may be found in st_ioc_flags and we try not to + * overlap with it. + */ +#define XSTAT_INFO_ENCRYPTED 0x00000001U /* File is encrypted */ +#define XSTAT_INFO_TEMPORARY 0x00000002U /* File is temporary (NTFS/CIFS) */ +#define XSTAT_INFO_FABRICATED 0x00000004U /* File was made up by filesystem */ +#define XSTAT_INFO_KERNEL_API 0x00000008U /* File is kernel API (eg: procfs/sysfs) */ +#define XSTAT_INFO_REMOTE 0x00000010U /* File is remote */ +#define XSTAT_INFO_OFFLINE 0x00000020U /* File is offline (CIFS) */ +#define XSTAT_INFO_AUTOMOUNT 0x00000040U /* Dir is automount trigger */ +#define XSTAT_INFO_AUTODIR 0x00000080U /* Dir provides unlisted automounts */ +#define XSTAT_INFO_NONSYSTEM_OWNERSHIP 0x00000100U /* File has non-system ownership details */ +#define XSTAT_INFO_HAS_ACL 0x00000200U /* File has an ACL of some sort */ +#define XSTAT_INFO_REPARSE_POINT 0x00000400U /* File is reparse point (NTFS/CIFS) */ +#define XSTAT_INFO_HIDDEN 0x00000800U /* File is marked hidden (DOS+) */ +#define XSTAT_INFO_SYSTEM 0x00001000U /* File is marked system (DOS+) */ +#define XSTAT_INFO_ARCHIVE 0x00002000U /* File is marked archive (DOS+) */ + #ifdef __KERNEL__ #define S_IRWXUGO (S_IRWXU|S_IRWXG|S_IRWXO) #define S_IALLUGO (S_ISUID|S_ISGID|S_ISVTX|S_IRWXUGO) @@ -60,6 +172,12 @@ #include <linux/time.h> struct kstat { + u32 query_flags; /* operational flags */ +#define KSTAT_QUERY_FLAGS (AT_FORCE_ATTR_SYNC) + u32 request_mask; /* what fields the user asked for */ + u32 result_mask; /* what fields the user got */ + u32 information; + u32 ioc_flags; /* inode flags (FS_IOC_GETFLAGS) */ u64 ino; dev_t dev; umode_t mode; @@ -67,14 +185,18 @@ struct kstat { uid_t uid; gid_t gid; dev_t rdev; + unsigned int tv_granularity; /* granularity of times (in nS) */ loff_t size; - struct timespec atime; + struct timespec atime; struct timespec mtime; struct timespec ctime; + struct timespec btime; /* file creation time */ unsigned long blksize; unsigned long long blocks; + u64 gen; /* inode generation */ + u64 version; /* data version */ + unsigned char volume_id[16]; /* volume identifier */ }; #endif - #endif diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 3de3acb..ff9f8d9 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -45,6 +45,8 @@ struct shmid_ds; struct sockaddr; struct stat; struct stat64; +struct xstat_parameters; +struct xstat; struct statfs; struct statfs64; struct __sysctl_args; @@ -858,4 +860,9 @@ asmlinkage long sys_process_vm_writev(pid_t pid, unsigned long riovcnt, unsigned long flags); +asmlinkage long sys_xstat(int dfd, const char __user *path, unsigned flags, + unsigned mask, struct xstat __user *buffer); +asmlinkage long sys_fxstat(unsigned fd, unsigned flags, + unsigned mask, struct xstat __user *buffer); + #endif

April 19, 2012

[PATCH 0/6] Extended file stat system call

by David Howells

Implement a pair of new system calls to provide extended and further extensible stat functions. The second of the associated patches is the main patch that provides these new system calls: ssize_t ret = xstat(int dfd, const char *filename, unsigned atflag, unsigned mask, struct xstat *buffer); ssize_t ret = fxstat(int fd, unsigned atflag, unsigned mask, struct xstat *buffer); which are more fully documented in the first patch's description. These new stat functions provide a number of useful features, in summary: (1) More information: creation time, inode generation number, data version number, flags/attributes. A subset of these is available through a number of filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). (2) Lightweight stat: Ask for just those details of interest, and allow a netfs (such as NFS) to approximate anything not of interest, possibly without going to the server. (3) Heavyweight stat: Force a netfs to go to the server, even if it thinks its cached attributes are up to date. (4) Allow the filesystem to indicate what it can/cannot provide: A filesystem can now say it doesn't support a standard stat feature if that isn't available. (5) Make the fields a consistent size on all arches, and make them large. (6) Can be extended by using more request flags and appending further data after the end of the standard return data. Note that no lstat() equivalent is required as that can be implemented through xstat() with atflag == 0. ======= PATCHES ======= Patch 1 defines the xstat() and fxstat() system calls. Patches 2-6 implement extended stat facilities for Ext4, AFS, NFS and CIFS, and make eCryptFS go to the lower filesystem for such details. ============== CONSIDERATIONS ============== Should fxstat() be implemented as xstat() with a NULL filename, using dfd as fd? Should the default for a network fs be to do an unconditional (heavyweight) stat with a flag to suppress going to the server to update the locally held attributes and flushing pending writebacks? Should things like the Windows Archive, Hidden and System bits be handled through IOC flags, perhaps expanded to 64-bits? Are these things useful to userspace other than Samba and userspace NFS servers? Is it useful to pass the volume ID out? Or is statfs() sufficient for this? Should I add a sixth argument to xstat(), mark it reserved and require that must be supplied as 0 to hedge against future use? Is there anything else I can usefully add at the moment? ========== TO BE DONE ========== Autofs, ntfs, btrfs, ... I should perhaps use u8/u32/u64 rather than uint8/32/64_t. Handle remote filesystems being offline and indicate this with XSTAT_INFO_OFFLINE. ======= TESTING ======= There's a test program attached to the description for the main patch. It can be run as follows: [root(a)andromeda tmp]# ./xstat -R /mnt/foo xstat(/mnt/foo) = 0 0000: 000081a40000ffef 0000000000000001 0000020000000000 0000100000080000 0020: 0000000000000000 0000000600000008 000000004f88499a 0000000136fd9208 0040: 000000004f88499a 0000000136fd9208 000000004f8849b9 0000000106daf187 0060: 000000004f8849b9 0000000106daf187 000000000000000c 000000000000000f 0080: 0000000000000008 00000000484ebbef 0000000000000025 5949ebd4711efd82 00a0: d3250b5c15d5e380 0000000000000000 0000000000000000 0000000000000000 00c0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 00e0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 results=ffef Size: 15 Blocks: 8 IO Block: 4096 regular file Device: 08:06 Inode: 12 Links: 1 Access: (0644/-rw-r--r--) Uid: 0 Gid: 0 Access: 2012-04-13 16:43:22.922587656+0100 Modify: 2012-04-13 16:43:53.115011975+0100 Change: 2012-04-13 16:43:53.115011975+0100 Create: 2012-04-13 16:43:22.922587656+0100 Inode version: 484ebbefh Data version: 25h Inode flags: 00080000 (-------- ----e--- -------- --------) Information: 00000200 (-------- -------- ------a- --------) Volume ID: 82fd1e71d4eb4959-80e3d5155c0b25d3 David --- David Howells (6): xstat: eCryptFS: Return extended attributes xstat: CIFS: Return extended attributes xstat: NFS: Return extended attributes xstat: AFS: Return extended attributes xstat: Ext4: Return extended attributes xstat: Add a pair of system calls to make extended file stats available arch/x86/syscalls/syscall_32.tbl | 2 arch/x86/syscalls/syscall_64.tbl | 2 fs/afs/inode.c | 29 ++- fs/afs/super.c | 7 + fs/cifs/cifsfs.h | 4 fs/cifs/cifsglob.h | 16 +- fs/cifs/dir.c | 2 fs/cifs/inode.c | 120 +++++++++++-- fs/ecryptfs/inode.c | 14 +- fs/ext4/ext4.h | 2 fs/ext4/file.c | 2 fs/ext4/inode.c | 32 +++ fs/ext4/namei.c | 2 fs/ext4/super.c | 1 fs/ext4/symlink.c | 2 fs/nfs/inode.c | 49 ++++- fs/nfs/super.c | 1 fs/stat.c | 350 +++++++++++++++++++++++++++++++++++--- include/linux/fcntl.h | 1 include/linux/fs.h | 4 include/linux/stat.h | 126 +++++++++++++- include/linux/syscalls.h | 7 + 22 files changed, 694 insertions(+), 81 deletions(-)

April 19, 2012

Re: [PATCH 4/4] jscript: Added Number.toPrecision implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17957 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 19, 2012

Re: [PATCH 3/4] jscript: Added Number.toExpontential implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17956 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 19, 2012

Re: [PATCH 2/4] jscript: Added Number.toFixed implementation

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17955 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 19, 2012

Re: [PATCH 1/3] ws2_32: Revise AcceptEx behavior to send completions for canceled sockets (resend 3, deferred).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mines.edu> writes: > @@ -256,10 +256,12 @@ void async_set_result( struct object *obj, unsigned int status, unsigned int tot > else > { > if (async->timeout) remove_timeout_user( async->timeout ); > + if (async->completion && async->data.cvalue && status != STATUS_ALERTED) > + add_completion( async->completion, async->comp_key, async->data.cvalue, status, total ); > + else if (async->completion && async->data.cvalue && status == STATUS_ALERTED) > + status = STATUS_SUCCESS; This looks pretty hackish, the server shouldn't have to care about the status values or patch them up for the client. -- Alexandre Julliard julliard(a)winehq.org

April 19, 2012

Re: Mono packaging status

by Jacek Caban

Hi Vincent, On 04/19/12 00:12, Vincent Povirk wrote: > If for some reason you want to try it, the current version is at > https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. > I think I will need a new home for the binaries, because github only > gives me enough space for about 5 of them. So, uh, don't count on that > URL sticking around. The right place for this is probably SourceForge, like all our other downloads. That's a detail to be handler during the final release through. Cheers, Jacek

April 19, 2012

Re: Mono packaging status

by Jerome Leclanche

On Wed, Apr 18, 2012 at 11:12 PM, Vincent Povirk <madewokherd(a)gmail.com>wrote: > > If for some reason you want to try it, the current version is at > https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. > I think I will need a new home for the binaries, because github only > gives me enough space for about 5 of them. So, uh, don't count on that > URL sticking around. > > You can probably message the github staff to get a space increase. IIRC they can special-case open source projects that need more space. J. Leclanche

April 19, 2012

Mono packaging status

by Vincent Povirk

So, I've finally had some time to work on Mono packaging. I think I have a sort of "first draft" ready. The goal is to create an MSI package of Mono, similar to the one we use for Gecko, which Wine will install automatically when updating a prefix, unless native mscoree is installed. This package will include all the Mono runtime files, as well as any registry keys and files that need to be installed to the Windows system for .NET compatibility. Anything .NET that we want to replace (including XNA, WPF, and msvcm libraries) will be included. Ideally, with this package installed, any official installers for .NET components will decide they are already installed and do nothing. To install native .NET, it will be necessary to uninstall the Mono package (using "wine uninstaller --remove '{E45D8920-A758-4088-B6C6-31DBB276992E}'", which will continue to work for the foreseeable future). Before the Mono package is installed, and after it is removed, no .NET registry keys or files will be present, so in theory the installers will just work (but in practice they probably will require work-arounds for Wine bugs). There will be only one package for 32-bit and 64-bit. Most of the compiled code is architecture-independent, so it doesn't make much sense to have separate packages. The Mono package versions will be loosely tied to Wine version. On prefix creation time, Wine will attempt to install the version it "prefers". Due to limitations of MSI, this may mean that Wine will upgrade Mono automatically but never downgrade it. Because the Mono API is stable, it should be possible to use any Mono package with any Wine version back to 1.5.1, which was the first version to search for the Mono runtime dll based on architecture. I'm currently publishing the source code at https://github.com/madewokherd/wine-mono, but I'm not sure if that is a good permanent home. I do want to keep it on github so I can make and accept pull requests. I'm using submodules, so it will be necessary to clone with --recursive and update the submodules from time to time. The build process requires mingw-w64 (both 32-bit and 64-bit), Wine, and a version of the Mono C sharp compiler (gmcs or dmcs, I think), and not surprisingly is done by running build-winemono.sh. There should never be any more requirements, and I'd like to keep the version requirements on those as broad as I can. I want this to be easy to build, so other people can work on it. The 64-bit part appears to work on Windows, but it is not useful on Wine currently. I'll be working on fixing that, or at least getting Alexandre bug reports and test cases so he can work on it. I think that when it is fixed, we'll have a lot more 64-bit processes than we used to, for better or worse. For now, the only way to install the package is with msiexec. The current version is based on Mono 2.11.0, which has a serious deadlock bug on Windows. This will need to be resolved before I can do an actual release. Otherwise, I'm not expecting much difference from the official Mono 2.10 packages for Windows. The XNA, WPF, and msvcm stuff is not ready yet. So, I know it's kind of crappy right now, and I'm not asking for testing so much as comments. If you are a packager of Wine, I would like to make sure you can build it, and that the resulting build works apart from that deadlock bug. If for some reason you want to try it, the current version is at https://github.com/downloads/madewokherd/wine-mono/winemono-0.0.2.msi. I think I will need a new home for the binaries, because github only gives me enough space for about 5 of them. So, uh, don't count on that URL sticking around.

April 18, 2012

Re: [PATCH 2/2] wininet: Add a new common module information struct

by Morten Rønne

Den 18-04-2012 17:42, Piotr Caban skrev: > On 04/16/12 22:03, Morten Rønne wrote: >> Add a new common module information struct for urlcache and functions to >> do initialization of the struct. This is intended to be a new way to >> more easily create Ansi and Unicode version of the functions, by doing a >> Ansi/Unicode preamble code that calls a common worker function that do >> the real work. > Is there any reason not to call Ansi function inside Unicode function? > > (This is the other way then it is done in most parts of wine, the > reason for this is that urlcache stores ansi strings internally. > Unicode urls should probably be converted using punycode encoding > (IdnToAscii?)). > > This patch is also introducing lots of unneeded Ansi/Unicode > conversions. I'm not sure if storing all url entry related information > inside a structure makes anything easier/more readable. Especially when > you need to make sure that a field is initialized before accessing it. > Hi By creating a common internal function for the Ansi and Unicode function you can use return to exit "early" in the function. Together with the common struct, this makes cleanup easy regardless of how little or how much work was done. All "tracking" of allocation is done in that one struct. This means that most top level functions can be written: if (AcquireIndex) do work ReleaseIndex Also from a TRACE point of view you only get one trace entry per call, with clear information whether an ansi or unicode function was called. Also by having a common function it is possible to reuse functions, e.g. RetrieveUrlCacheEntryStream can use RetrieveUrlCacheEntry common function in its implementation. This can be done because the locking/release is done once in the top level entry function. Doing a general rule of Unicode calls Ansi function, you will end up with even more round trip conversions, because Unicode function would convert to ansi, and the ansi function would convert back to unicode in some cases, at least as the code is now. If you are to avoid this, you have to rewrite all the internal functions to use ansi only in its processing (see comment about prefix below). Regarding Ansi/Unicode conversions. If you read the current code, you will find that certain functions will do a round trip conversion between Ansi/Unicode already. My code will only do one conversion ever, once it is fully implemented. The current implementation requires both the unicode version and the ansi version (at least of the url), because the url prefix in the container struct, used to find the container is in unicode and the internal value used inside the cache is ansi. The same is true about all file processing which is done in unicode. Regarding the actual conversion of ansi/unicode I have simply done what is already being done in the module. If there is another way, feel free to send the exact code that I should use or send a patch after. Creating a few common functions will ensure that all variables needed are initialized properly, so there is no need for testing whether or not a value is filled or not. I believe that what I propose here will make the implementation of functions simpler and safer. Best Regards Morten Rønne

April 18, 2012

Re: [PATCH 1/2] wininet: Update structs with more information in preparation for implementation of more functionality.

by Morten Rønne

Den 18-04-2012 15:04, Piotr Caban skrev: > On 04/16/12 22:00, Morten Rønne wrote: > + DWORD AllocationTable[0xF6C]; > There are defines describing allocation table size. It's better to > define it as BYTE AllocationTable[ALLOCATION_TABLE_SIZE]; > I intend to make use of the fact that the allocation table can be used as DWORD as well as BYTE. I will update using defines. BR Morten Rønne

April 18, 2012

Re: Patch 85420

by Christian Costa

2012/4/17 Michael Stefaniuc <mstefani(a)redhat.com> > On 04/17/2012 09:46 PM, Marcus Meissner wrote: > > On Tue, Apr 17, 2012 at 09:10:45PM +0200, Christian Costa wrote: > >> Patch http://source.winehq.org/patches/data/85420 is marked as > >> pending. I've taken a look but I still don't understand what's > >> wrong. > >> Is there anything I've missed ? > > > > I stopped reading at this line: > > > > + *frame = > (LPDIRECT3DRMFRAME)(&impl_from_IDirect3DRMFrame3(This->parent)->IDirect3DRMFrame2_iface); > > > > You are doing something very wrong if you need to cast this way. > That's just the stupid obfuscation introduced by using LPDIRECT3DRMFRAME > instead of (IDirect3DRMFrame *) and then the cast might be plausible > (e.g. a function taking an IFace* type but which is implemented by the > IFace2 interface). > > Yes that's exactly the case. > There are three other issues with that line though that kill it: > - For type safety reasons impl_from_IFace() needs to be used *only* in > variable declarations. > Ok. Does not seem to be explicit on the COM guidelines. Could you make it more explicit on the wiki ? > - Calling impl_from_IFace() on interface pointers outside methods that > implement that interface are verboten. > Same as above. > - Both above points can be completely avoided by making the parent field > be "IDirect3DRMFrameImpl *parent". > Ok. I will do that. > > Christian

April 18, 2012

Re: gdiplus: Use StretchBlt instead of GdiAlphaBlend if device doesn't support alpha blending. Resend.

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > I think if you start by checking for CompositingModeSourceCopy and > make sure you don't write the 100% transparent pixels, then force that > mode on HDC's that can't alpha blend in a later patch, I'll support > that. As it is now, I'm only neutral to this change. I'm not planning to go that far, but I'll certainly look at problems (if any) caused by this patch. -- Dmitry.

April 18, 2012

Re: gdiplus: Use StretchBlt instead of GdiAlphaBlend if device doesn't support alpha blending. Resend.

by Vincent Povirk

I think if you start by checking for CompositingModeSourceCopy and make sure you don't write the 100% transparent pixels, then force that mode on HDC's that can't alpha blend in a later patch, I'll support that. As it is now, I'm only neutral to this change. On Wed, Apr 18, 2012 at 9:58 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> This patch makes printing of PNG and other images work from applications >> which use gdiplus for that. >> >> Printer drivers can't support transparency or alpha blending in any way. >> This patch was tested with wide range of images (some mixed with other >> graphics and text), and output matches what native gdiplus does. > > Is there anything else I could provide in helping to get this patch accepted? > > -- > Dmitry. > >

April 18, 2012

Re: [PATCH 2/2] wininet: Add a new common module information struct

by Piotr Caban

On 04/16/12 22:03, Morten Rønne wrote: > Add a new common module information struct for urlcache and functions to > do initialization of the struct. This is intended to be a new way to > more easily create Ansi and Unicode version of the functions, by doing a > Ansi/Unicode preamble code that calls a common worker function that do > the real work. Is there any reason not to call Ansi function inside Unicode function? (This is the other way then it is done in most parts of wine, the reason for this is that urlcache stores ansi strings internally. Unicode urls should probably be converted using punycode encoding (IdnToAscii?)). This patch is also introducing lots of unneeded Ansi/Unicode conversions. I'm not sure if storing all url entry related information inside a structure makes anything easier/more readable. Especially when you need to make sure that a field is initialized before accessing it.

April 18, 2012

Re: gdiplus: Use StretchBlt instead of GdiAlphaBlend if device doesn't support alpha blending. Resend.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > This patch makes printing of PNG and other images work from applications > which use gdiplus for that. > > Printer drivers can't support transparency or alpha blending in any way. > This patch was tested with wide range of images (some mixed with other > graphics and text), and output matches what native gdiplus does. Is there anything else I could provide in helping to get this patch accepted? -- Dmitry.

April 18, 2012

Re: winex11.drv: Windows always generates VK_DECIMAL for Del/. on a keypad.

by Dmitry Timoshkov

Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Windows always generates VK_DECIMAL for Del/. on a keypad while some > X11 keyboard layouts generate XK_KP_Separator instead of XK_KP_Decimal > in order to produce a locale dependent numeric separator. > > X11 handles XK_KP_Separator same way as XK_KP_Decimal for all tested > keyboard layouts, so passing XK_KP_Separator instead of XK_KP_Decimal > to XKeysymToKeycode doesn't break things. Pressing Del/. with NumLock > turned on still correctly generates '.' or ',' depending on keyboard > layout and matches what Windows does. > > This patch fixes an application which uses VK_DECIMAL as a sign to break > the input string and insert a separator while entering a currency/price. Is there anything else I could provide in helping to get this patch accepted? -- Dmitry.

April 18, 2012

Re: mshtml: Copy filter value in HTMLElement_clone

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17938 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 18, 2012

Re: [PATCH 2/2] wininet: Add a new common module information struct

by Jacek Caban

Hi Morten, On 04/16/12 22:03, Morten Rønne wrote: > typedef struct _HASH_CACHEFILE_ENTRY > { > CACHEFILE_ENTRY CacheFileEntry; > DWORD dwAddressNext; > DWORD dwHashTableNumber; > - struct _HASH_ENTRY HashTable[HASHTABLE_SIZE]; > -} HASH_CACHEFILE_ENTRY; > + HASH_ENTRY HashTable[HASHTABLE_SIZE]; > +} HASH_CACHEFILE_ENTRY, *LPHASH_CACHEFILE_ENTRY; > > typedef struct _DIRECTORY_DATA > { > @@ -187,13 +187,56 @@ typedef struct _URLCACHECONTAINER > HANDLE hMapping; /* handle of file mapping */ > DWORD file_size; /* size of file when mapping was opened */ > HANDLE hMutex; /* handle of mutex */ > -} URLCACHECONTAINER; > +} URLCACHECONTAINER, *LPURLCACHECONTAINER; Please don't use this kind of defined. LP* types make the code less readable for no good reason. Cheers, Jacek

April 18, 2012

Re: [PATCH 1/2] wininet: Update structs with more information in preparation for implementation of more functionality.

by Piotr Caban

On 04/16/12 22:00, Morten Rønne wrote: + DWORD AllocationTable[0xF6C]; There are defines describing allocation table size. It's better to define it as BYTE AllocationTable[ALLOCATION_TABLE_SIZE];

April 18, 2012

Re: [PATCH 2/2] jscript: Correctly handle empty matches in String.replace

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17935 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 18, 2012

Re: [7/7] server: Propagate an error code returned by token_access_check() to the client. Resend.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17934 Your paranoid android. === TEST64_W7SP1 (32 bit sync) === sync.c:924: Test failed: ChangeTimerQueueTimer

April 18, 2012

Re: SymEnumSymbolsForAddr in dbghelp.dll

by Roger Cruz

Any recent bug fixes in the dbghelp.dll (since 1.36.3 which is my development base)? For some reason, symt_find_nearest() is not finding the address which corresponds to the MessageBoxW() in user32.dll. I have stepped through the function and it appears that the address for MessageBoxW is not in the sorted list of addresses as shown in the log below symt_find_nearest (module=0x455604b8, addr=0x458bc19c) at symbol.c:976 973 if (cmp_sorttab_addr(module, mid, addr) < 0) (gdb) p low $235 = 0xa85 (gdb) p high $236 = 0xa88 (gdb) p mid $237 = 0xa86 (gdb) s cmp_sorttab_addr (module=0x455604b8, idx=0xa86, addr=0x458bc19c) at symbol.c:54 54 symt_get_address(&module->addr_sorttab[idx]->symt, &ref); (gdb) n 55 return cmp_addr(ref, addr); (gdb) p ref $239 = 0x458bc458 <-- this address at idx=0xa86 is past the one I'm looking for (gdb) p addr $240 = 0x458bc19c <---- this is the address of MessageBoxW that I am searching for. After returning from this call, we exit the while (high > low + 1) and then return the "incorrect" symbol at idx=0xa85 which is the closest given the sorted address but not the one I was looking for. 98 symt_get_address(&module->addr_sorttab[low]->symt, &ref_addr); (gdb) p low $249 = 0xa85 (gdb) p ref_addr $250 = 0x458bbb18 (gdb) info symbol ref_addr MSGBOX_OnInit + 3044 in section .text of /development/rcruz/sandbox/wine/installs/wine-1.3.36/lib/wine/user32.dll.so (gdb) n 1003 return module->addr_sorttab[low]; So why isn't the address 0x458bc19c for MessageBoxW found in the sorted array between addr 0x458bbb18 and 0x458bc458? did it not get added to the sorted list of symbols at all? or incorrectly? There are close to 8000 symbols in user32.dll so obviously I haven't looked through this entire array to see if this function got inserted into the wrong place. I will continue to debug this but I figure I ask first in case there is a known issue which has been address in a subsequent release. Regards Roger ________________________________ From: Roger Cruz <roger_r_cruz(a)yahoo.com> To: André Hentschel <nerv(a)dawncrow.de>; "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Sent: Tuesday, April 17, 2012 11:11 PM Subject: Re: SymEnumSymbolsForAddr in dbghelp.dll I already changed the code to use SymEnumSymbols and SymSetContext to specify the address of the symbol I want to look for. A little more cumbersome but equivalent in functionality. I'm currently in the process of debugging why symt_find_nearest() is not properly identifying the correct function symbol associated with the address it is being passed in. The binary search in that function seems to stop short of the actual symbol. With regards to winebuild and *.spec files, I had examined the code and was pretty sure that stub meant not implemented but I just wanted to confirm. Sometimes I ask also to see if anyone else is working on something similar so I don't duplicate the work and to get additional pointers on who to talk to like Juan did. Much greatful for your help and all of you other wine developers out there Regards, Roger R. Cruz ________________________________ > *From:* Roger Cruz <roger_r_cruz(a)yahoo.com> > *To:* "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > *Sent:* Monday, April 16, 2012 9:13 PM > *Subject:* SymEnumSymbolsForAddr in dbghelp.dll > > > I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? > > Thanks > Roger R. Cruz Have a look at SymEnumSymbols (and SymEnumSymbolsW), it seems everything needed for SymEnumSymbolsForAddr is already available or needs only minor changes. PS: The fact that you don't know Wine basics like spec files is putting you in a bad position to attack wine internals like winebuild/ntdll, i suggest to read the docs (http://www.winehq.org/documentation) and the regarding wiki Developer pages (http://wiki.winehq.org/Developers) -- Best Regards, André Hentschel

April 18, 2012

Re: SymEnumSymbolsForAddr in dbghelp.dll

by Roger Cruz

I already changed the code to use SymEnumSymbols and SymSetContext to specify the address of the symbol I want to look for. A little more cumbersome but equivalent in functionality. I'm currently in the process of debugging why symt_find_nearest() is not properly identifying the correct function symbol associated with the address it is being passed in. The binary search in that function seems to stop short of the actual symbol. With regards to winebuild and *.spec files, I had examined the code and was pretty sure that stub meant not implemented but I just wanted to confirm. Sometimes I ask also to see if anyone else is working on something similar so I don't duplicate the work and to get additional pointers on who to talk to like Juan did. Much greatful for your help and all of you other wine developers out there Regards, Roger R. Cruz ________________________________ > *From:* Roger Cruz <roger_r_cruz(a)yahoo.com> > *To:* "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > *Sent:* Monday, April 16, 2012 9:13 PM > *Subject:* SymEnumSymbolsForAddr in dbghelp.dll > > > I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? > > Thanks > Roger R. Cruz Have a look at SymEnumSymbols (and SymEnumSymbolsW), it seems everything needed for SymEnumSymbolsForAddr is already available or needs only minor changes. PS: The fact that you don't know Wine basics like spec files is putting you in a bad position to attack wine internals like winebuild/ntdll, i suggest to read the docs (http://www.winehq.org/documentation) and the regarding wiki Developer pages (http://wiki.winehq.org/Developers) -- Best Regards, André Hentschel

April 18, 2012

Re: SymEnumSymbolsForAddr in dbghelp.dll

by André Hentschel

Am 17.04.2012 03:30, schrieb Roger Cruz: > Guys, > > Just a quick status update on the symbol lookup and an explanation of what this question is all about. Basically, I have loaded the dbghelp file successfully and loaded all of the symbols for the module (aka, library, dll, etc) being linked. I then tried to invoke this function SymEnumSymbolsForAddrto enumerate each function's arguments and lo and behold, the damn function is not implemented in Wine.. but where there is a will, there is a way. I recalled that Wine has its own debugger and they implement the backtrace capability so I'm looking to see how they enumerate the arguments. I will let you know more soon. > > Roger > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Roger Cruz <roger_r_cruz(a)yahoo.com> > *To:* "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > *Sent:* Monday, April 16, 2012 9:13 PM > *Subject:* SymEnumSymbolsForAddr in dbghelp.dll > > > I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? > > Thanks > Roger R. Cruz Have a look at SymEnumSymbols (and SymEnumSymbolsW), it seems everything needed for SymEnumSymbolsForAddr is already available or needs only minor changes. PS: The fact that you don't know Wine basics like spec files is putting you in a bad position to attack wine internals like winebuild/ntdll, i suggest to read the docs (http://www.winehq.org/documentation) and the regarding wiki Developer pages (http://wiki.winehq.org/Developers) -- Best Regards, André Hentschel

April 17, 2012

Re: winebuild port to ARM?

by André Hentschel

Am 17.04.2012 03:09, schrieb Roger Cruz: > Hi Andre, > > I am willing to help as much as my knowledge allows me to port this. The last time I wrote anything in ARM was about 15+ years ago so my knowledge of it is rather limited. I'm also trying to understand what every line of the assembly code is doing in x86. If someone with more knowledge were willing to port this file for us, it would be a great start :-) but failing that, I can fold up my sleeves and take a crack at it. First: Please bottom post on this list. I doubt someone else will port it anytime soon, so maybe you start trying it and i try to help you as much as i can or you wait until i get time to do it myself. -- Best Regards, André Hentschel

April 17, 2012

Re: Patch 85420

by Michael Stefaniuc

On 04/17/2012 09:46 PM, Marcus Meissner wrote: > On Tue, Apr 17, 2012 at 09:10:45PM +0200, Christian Costa wrote: >> Patch http://source.winehq.org/patches/data/85420 is marked as >> pending. I've taken a look but I still don't understand what's >> wrong. >> Is there anything I've missed ? > > I stopped reading at this line: > > + *frame = (LPDIRECT3DRMFRAME)(&impl_from_IDirect3DRMFrame3(This->parent)->IDirect3DRMFrame2_iface); > > You are doing something very wrong if you need to cast this way. That's just the stupid obfuscation introduced by using LPDIRECT3DRMFRAME instead of (IDirect3DRMFrame *) and then the cast might be plausible (e.g. a function taking an IFace* type but which is implemented by the IFace2 interface). There are three other issues with that line though that kill it: - For type safety reasons impl_from_IFace() needs to be used *only* in variable declarations. - Calling impl_from_IFace() on interface pointers outside methods that implement that interface are verboten. - Both above points can be completely avoided by making the parent field be "IDirect3DRMFrameImpl *parent". > It probably also needs explicit sign-off drom the d3d folks as it handles funny refcounting. Not really, this is plain COM stuff. bye michael

April 17, 2012

Re: Patch 85420

by Marcus Meissner

On Tue, Apr 17, 2012 at 09:10:45PM +0200, Christian Costa wrote: > Hi, > > Patch http://source.winehq.org/patches/data/85420 is marked as > pending. I've taken a look but I still don't understand what's > wrong. > Is there anything I've missed ? I stopped reading at this line: + *frame = (LPDIRECT3DRMFRAME)(&impl_from_IDirect3DRMFrame3(This->parent)->IDirect3DRMFrame2_iface); You are doing something very wrong if you need to cast this way. It probably also needs explicit sign-off drom the d3d folks as it handles funny refcounting. Ciao, Marcus

April 17, 2012

Patch 85420

by Christian Costa

Hi, Patch http://source.winehq.org/patches/data/85420 is marked as pending. I've taken a look but I still don't understand what's wrong. Is there anything I've missed ? Thanks Christian

April 17, 2012

Re: wsnmp32: New stub dll (resend)

by Alexandre Julliard

Stefan Leichter <Stefan.Leichter(a)camline.com> writes: > @@ -0,0 +1,49 @@ > +# imported from D-Link EMS by ordinal > +320 stub SnmpSetPort > +# > +@ stub SnmpCancelMsg > +@ stub SnmpCleanup > +@ stub SnmpClose > +@ stub SnmpContextRoStr > +@ stub _SnmpConveyAgentAddress > +@ stub SnmpCountVbl > +@ stub SnmpCreatePdu > +@ stub SnmpCreateSession > +@ stub SnmpCreateVbl > +@ stub SnmpDecodeMsg > +@ stub SnmpDeleteVb > +@ stub SnmpDuplicatePdu > +@ stub SnmpDuplicateVbl > +@ stub SnmpEncodeMsg > +@ stub SnmpEntityTpStr > +@ stub SnmpFreeContext > +@ stub SnmpFreeDescriptor > +@ stub SnmpFreeEntity > +@ stub SnmpFreePdu > +@ stub SnmpFreeVbl > +@ stub SnmpGetLastError > +@ stub SnmpGetPduData > +@ stub SnmpGetRetransmitMode > +@ stub SnmpGetRetry > +@ stub SnmpGetTimeout > +@ stub SnmpGetVb > +@ stub SnmpGetVendorInfo > +@ stub SnmpListen > +@ stub SnmpOidCompare > +@ stub SnmpOidCopy > +@ stub SnmpOidToStr > +@ stub SnmpOpen > +@ stub SnmpRecvMsg > +@ stub SnmpRegister > +@ stub SnmpSendMsg > +@ stub _SnmpSetAgentAddress > +@ stub SnmpSetPdu > +@ stub SnmpSetRetransmitMode > +@ stub SnmpSetRetry > +@ stub SnmpSetTimeout > +@ stub SnmpSetTranslateMode > +@ stub SnmpSetVb > +@ stub SnmpStartup > +@ stub SnmpStrToContext > +@ stub SnmpStrToEntity > +@ stub SnmpStrToOid They should probably all be ordinals, also some of the names are wrong. -- Alexandre Julliard julliard(a)winehq.org

April 17, 2012

Re: New forum software

by Jeremy Newman

I have been considering using IP.Board (http://www.invisionpower.com/products/board/) as the forum software. A few of my favorite sites are using it, and I rather like it. It is not free however. Granted, this would eliminate the mailing list gateway, but as discussed prior, we are good with that. -N On 04/17/2012 10:10 AM, Jeremy Newman wrote: > Someday. > > -N > > On 04/16/2012 08:30 PM, Vitaliy Margolen wrote: >> Can I ask when we'll have the new forum software installed? It's been >> discussed ages ago and we still using the same old crappy version. >> >> Vitaliy. >> >> > >

April 17, 2012

Re: New forum software

by Jeremy Newman

Someday. -N On 04/16/2012 08:30 PM, Vitaliy Margolen wrote: > Can I ask when we'll have the new forum software installed? It's been > discussed ages ago and we still using the same old crappy version. > > Vitaliy. > >

April 17, 2012

Re: New forum software

by Jerome Leclanche

On Tue, Apr 17, 2012 at 11:13 AM, Frédéric Delanoy < frederic.delanoy(a)gmail.com> wrote: > On Tue, Apr 17, 2012 at 03:30, Vitaliy Margolen <wine-devel(a)kievinfo.com> > wrote: > > Can I ask when we'll have the new forum software installed? It's been > > discussed ages ago and we still using the same old crappy version. > > IIRC there were some issues with the forum <=> mailing list interactions. > > BTW, a new wiki version would also be nice, e.g. something that allows > you to preview changes (diff only, *not* full page) before > publication. MoinMoin doesn't allow that, even in recent versions. > > Frédéric > Why is moinmoin used instead of mediawiki anyway? J. Leclanche

April 17, 2012

Re: gdi32/dibdrv: don't add_join if points are coincident in wide_line_segments (try 2)

by Alexandre Julliard

Daniel Lehman <dlehman(a)esri.com> writes: > Was mistakenly sent to wine-devel > > try 2 - integrate into existing tests; updated commit message > > I think the only points in the middle of the points array can cause > the crash I was seeing. wide_pen_lines trims coincident points/empty > segments from the beginning and end of the array, so the > wine_line_segment calls before and after the for loop I modified will > always return valid faces It doesn't work here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so dib.c && touch dib.ok dib.c:1324: Test failed: 8888: wide pen - empty segments: expected hash 5bac9c515315bced1ac5cb46a771690d02040278 got 56cc0584aaeb790419b343dae0ea09591c384ac4 dib.c:1324: Test failed: 8888 - bitfields: wide pen - empty segments: expected hash 5bac9c515315bced1ac5cb46a771690d02040278 got 56cc0584aaeb790419b343dae0ea09591c384ac4 dib.c:1324: Test failed: a8b8g8r8: wide pen - empty segments: expected hash 1aa5e414c797fd74fe1400757548ef79650fe994 got ee5a5dc02ec61af2462c265424943049ea7c23eb dib.c:1324: Test failed: r10g10b10: wide pen - empty segments: expected hash 65f7fc7219e7cc29d20aeab7d38a60ac6c303726 got d7ee8801ea0c3e7cf012153b77bd7ba9b388f459 dib.c:1324: Test failed: r6g6b6: wide pen - empty segments: expected hash b1e3aeac484f49b1874033509924627ef0a4c3bc got 906c2d8da24180ccbe84fd4fd5ba964d8f9a3a44 dib.c:1324: Test failed: 24: wide pen - empty segments: expected hash f11f301314f9729ab351294a4d8a72b72fc2491d got 9433b11e4190cf1d77f4b84017e8561884ccd73c dib.c:1324: Test failed: r5g5b5: wide pen - empty segments: expected hash ffa75c684138fdb296f4001e2dc36ed1ae33065b got e141eb6b73e91eb2e4b5fd31688084d4b4c70d30 dib.c:1324: Test failed: r4g4b4: wide pen - empty segments: expected hash 9aa687dc13503e3ff4e12e67c361ca140cbdb48d got 27afb67bda17491c7806f1a42650deb9d47bba71 dib.c:1324: Test failed: 8 color: wide pen - empty segments: expected hash 7897ba51f37e01c6a54a2733459e79285b52d213 got d905bc3cd08fc4a7110608ec8b80e494077e859e dib.c:1324: Test failed: 8 grayscale: wide pen - empty segments: expected hash 88eb0c6542a2c03036241cdb5e08f13401a92f31 got bef8347c9bc96d709aaf002fcf6b4da66e5267e7 dib.c:1324: Test failed: 8: wide pen - empty segments: expected hash 00b34f58bb4876b597fad1a275bccb2c9a95967b got 3f318b982da1b8d26eff59ed8c6d7ce6a84f857a dib.c:1324: Test failed: 4: wide pen - empty segments: expected hash 9b5ecb81cf32c34c43cb13310e4b479b6909f3ec got 10271cb9b746fb9b507a9322c16f1279deb69a95 dib.c:1324: Test failed: 4 grayscale: wide pen - empty segments: expected hash 048ce4615962675d66b648631dc556238a86b4df got 9cf16c3165ac241aa6fb50bb0a05c3548fbaeb43 dib.c:1324: Test failed: 1: wide pen - empty segments: expected hash 1dde794388a3ca3ac710acc0aff97f7df70687e5 got e203905ad4c0a609b5ac78e66714b66ffe792b8b make[1]: *** [dib.ok] Error 14 -- Alexandre Julliard julliard(a)winehq.org

April 17, 2012

Re: [2/4] server: Add access mapping for a named pipe device object, adjust its default access rights. Resend.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> Why do you need this for the device? > > > > Because of > > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so pipe.c && touch pipe.ok > > pipe.c:109: Test failed: WaitNamedPipe failed (3) > > pipe.c:116: Test failed: wrong error 3 > > pipe.c:109: Test failed: WaitNamedPipe failed (3) > > pipe.c:116: Test failed: wrong error 3 > > > > WaitNamedPipeW() opens a pipe device with FILE_READ_ATTRIBUTES. > > That doesn't mean it should use the same access as a named pipe object. Yes, but currently it fails because default read access rights don't contain FILE_READ_ATTRIBUTES, and while write access does specify FILE_CREATE_PIPE_INSTANCE all access doesn't contain FILE_CREATE_PIPE_INSTANCE access. -- Dmitry.

April 17, 2012

Re: [2/4] server: Add access mapping for a named pipe device object, adjust its default access rights. Resend.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> Why do you need this for the device? > > Because of > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so pipe.c && touch pipe.ok > pipe.c:109: Test failed: WaitNamedPipe failed (3) > pipe.c:116: Test failed: wrong error 3 > pipe.c:109: Test failed: WaitNamedPipe failed (3) > pipe.c:116: Test failed: wrong error 3 > > WaitNamedPipeW() opens a pipe device with FILE_READ_ATTRIBUTES. That doesn't mean it should use the same access as a named pipe object. -- Alexandre Julliard julliard(a)winehq.org

April 17, 2012

Re: [2/4] server: Add access mapping for a named pipe device object, adjust its default access rights. Resend.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > Why do you need this for the device? Because of ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so pipe.c && touch pipe.ok pipe.c:109: Test failed: WaitNamedPipe failed (3) pipe.c:116: Test failed: wrong error 3 pipe.c:109: Test failed: WaitNamedPipe failed (3) pipe.c:116: Test failed: wrong error 3 WaitNamedPipeW() opens a pipe device with FILE_READ_ATTRIBUTES. -- Dmitry.

April 17, 2012

Re: [2/4] server: Add access mapping for a named pipe device object, adjust its default access rights. Resend.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > @@ -238,7 +238,7 @@ static const struct object_ops named_pipe_device_ops = > no_satisfied, /* satisfied */ > no_signal, /* signal */ > named_pipe_device_get_fd, /* get_fd */ > - no_map_access, /* map_access */ > + named_pipe_map_access, /* map_access */ > default_get_sd, /* get_sd */ > default_set_sd, /* set_sd */ > named_pipe_device_lookup_name, /* lookup_name */ > @@ -270,10 +270,10 @@ static void named_pipe_dump( struct object *obj, int verbose ) > > static unsigned int named_pipe_map_access( struct object *obj, unsigned int access ) > { > - if (access & GENERIC_READ) access |= STANDARD_RIGHTS_READ; > + if (access & GENERIC_READ) access |= STANDARD_RIGHTS_READ | FILE_READ_ATTRIBUTES; > if (access & GENERIC_WRITE) access |= STANDARD_RIGHTS_WRITE | FILE_CREATE_PIPE_INSTANCE; > if (access & GENERIC_EXECUTE) access |= STANDARD_RIGHTS_EXECUTE; > - if (access & GENERIC_ALL) access |= STANDARD_RIGHTS_ALL; > + if (access & GENERIC_ALL) access |= STANDARD_RIGHTS_ALL | FILE_READ_ATTRIBUTES | FILE_CREATE_PIPE_INSTANCE; > return access & ~(GENERIC_READ | GENERIC_WRITE | GENERIC_EXECUTE | GENERIC_ALL); Why do you need this for the device? -- Alexandre Julliard julliard(a)winehq.org

April 17, 2012

Re: [PATCH 2/3] Added support for shadowing of element pseudo-variables

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17915 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 17, 2012

Re: New forum software

by Frédéric Delanoy

On Tue, Apr 17, 2012 at 03:30, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > Can I ask when we'll have the new forum software installed? It's been > discussed ages ago and we still using the same old crappy version. IIRC there were some issues with the forum <=> mailing list interactions. BTW, a new wiki version would also be nice, e.g. something that allows you to preview changes (diff only, *not* full page) before publication. MoinMoin doesn't allow that, even in recent versions. Frédéric

April 17, 2012

Re: [4/4] server: Propagate an error code returned by token_access_check() to the client. Resend.

by Dmitry Timoshkov

Marvin <testbot(a)testbot.winehq.org> wrote: > === W7PROX64 (64 bit sync) === > sync.c:923: Test failed: DeleteTimerQueueTimer > sync.c:924: Test failed: ChangeTimerQueueTimer This failure has nothing to do with that patch either. -- Dmitry.

April 17, 2012

Re: kernel32: Add more memory access checks.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17913 Your paranoid android. === TEST64_W7SP1 (64 bit virtual) === virtual.c:854: Test failed: got size 0x100000 virtual.c:935: Test failed: got size 0x100000

April 17, 2012

Re: [3/4] server: Perform an access check for kernel objects without a security descriptor using access rights of the owner'

by Dmitry Timoshkov

Marvin <testbot(a)testbot.winehq.org> wrote: > === WVISTAADM (32 bit sync) === > sync.c:923: Test failed: DeleteTimerQueueTimer This failure has nothing to do with that patch. -- Dmitry.

April 17, 2012

Re: [4/4] server: Propagate an error code returned by token_access_check() to the client. Resend.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17912 Your paranoid android. === W7PROX64 (64 bit sync) === sync.c:923: Test failed: DeleteTimerQueueTimer sync.c:924: Test failed: ChangeTimerQueueTimer

April 17, 2012

Re: [3/4] server: Perform an access check for kernel objects without a security descriptor using access rights of the owner'

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17911 Your paranoid android. === WVISTAADM (32 bit sync) === sync.c:923: Test failed: DeleteTimerQueueTimer

April 17, 2012

New forum software

by Vitaliy Margolen

Can I ask when we'll have the new forum software installed? It's been discussed ages ago and we still using the same old crappy version. Vitaliy.

April 17, 2012

Re: SymEnumSymbolsForAddr in dbghelp.dll

by Roger Cruz

Guys, Just a quick status update on the symbol lookup and an explanation of what this question is all about. Basically, I have loaded the dbghelp file successfully and loaded all of the symbols for the module (aka, library, dll, etc) being linked. I then tried to invoke this function SymEnumSymbolsForAddrto enumerate each function's arguments and lo and behold, the damn function is not implemented in Wine.. but where there is a will, there is a way. I recalled that Wine has its own debugger and they implement the backtrace capability so I'm looking to see how they enumerate the arguments. I will let you know more soon. Roger ________________________________ From: Roger Cruz <roger_r_cruz(a)yahoo.com> To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> Sent: Monday, April 16, 2012 9:13 PM Subject: SymEnumSymbolsForAddr in dbghelp.dll I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? Thanks Roger R. Cruz

April 17, 2012

SymEnumSymbolsForAddr in dbghelp.dll

by Roger Cruz

I wrote a simple piece of code that uses dbghelp.dll's SymEnumSymbolsForAddr() but when I went to search for its code in Wine, it looks to be missing. The dbghelp.spec has that function listed as "stub". What does stub mean in this context? Does it mean the function is not implemented? Are there any plans to? Thanks Roger R. Cruz

April 17, 2012

Re: winebuild port to ARM?

by Roger Cruz

Hi Andre, I am willing to help as much as my knowledge allows me to port this. The last time I wrote anything in ARM was about 15+ years ago so my knowledge of it is rather limited. I'm also trying to understand what every line of the assembly code is doing in x86. If someone with more knowledge were willing to port this file for us, it would be a great start :-) but failing that, I can fold up my sleeves and take a crack at it. Roger ________________________________ From: André Hentschel <nerv(a)dawncrow.de> To: Wine Devel <wine-devel(a)winehq.org> Sent: Friday, April 13, 2012 11:13 AM Subject: Re: winebuild port to ARM? Am 13.04.2012 08:55, schrieb Roger Cruz: > Is anyone interested in helping me port the x86 specific code in Winebuild to ARM so I can get the relay tracing working? I am relatively new to ARM so any help would be appreciate it. > > Thanks > Roger R. Cruz > > *From:* Roger Cruz <roger_r_cruz(a)yahoo.com> > *To:* "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > *Sent:* Monday, April 9, 2012 11:16 PM > *Subject:* winebuild port to ARM? > > Has anyone worked or is currently working on porting the x86 specific code in Winebuild to ARM? Specifically the relay.c file? > It's on my todo list: http://wiki.winehq.org/ARM It won't be that easy and not only winebuild is involved, but also ntdll. I'm not that good in understanding x86 asm, but the code is partially commented, still i need to figure out the intention of every single line. How would you imagine "helping you to port"? -- Best Regards, André Hentschel

April 17, 2012

[shlwapi] Add NULL checks to StrCpyW and StrCatW

by carlo.bramix＠libero.it

Hello friends, according to these results, it looks like the test I added in the patch crashes win2k SP4 but it works on all others. And it does not seem to be a thing that it can be resolved with dynamic library loading. So, what should I do? Do I need to comment them like it has been done (for example) into test_StrChrA()? Do I need to remove interely the test and revive previous patch? Please excuse my inexperience... Sincerely, Carlo Bramini. >----Messaggio originale---- >Da: testbot(a)testbot.winehq.org >Data: 16/04/2012 22.48 >A: <carlo.bramix(a)libero.it> >Ogg: TestBot job 17900 results: [shlwapi] Add NULL checks to StrCpyW and StrCatW > >VM Status Number of test failures >WINEBUILD completed >WNT4WSSP6 completed 0 >W2KPROSP4 completed 1 >WXPPROSP3 completed 0 >W2K3R2SESP2 completed 0 >WVISTAADM completed 0 >W2K8SE completed 0 >W7PRO completed 0 >W7PROX64 completed 0 >TEST64_W7SP1 completed 0 >W7PROX64 completed 0 >TEST64_W7SP1 completed 0 > >=== WINEBUILD (build) === >No build failures found > >=== WNT4WSSP6 (32 bit string) === >No test failures found > >=== W2KPROSP4 (32 bit string) === > >shlwapi: >string: unhandled exception c0000005 at 77C7F8A8 > >=== WXPPROSP3 (32 bit string) === >No test failures found > >=== W2K3R2SESP2 (32 bit string) === >No test failures found > >=== WVISTAADM (32 bit string) === >No test failures found > >=== W2K8SE (32 bit string) === >No test failures found > >=== W7PRO (32 bit string) === >No test failures found > >=== W7PROX64 (32 bit string) === >No test failures found > >=== TEST64_W7SP1 (32 bit string) === >No test failures found > >=== W7PROX64 (64 bit string) === >No test failures found > >=== TEST64_W7SP1 (64 bit string) === >No test failures found

April 16, 2012

Re: [shlwapi] Add NULL checks to StrCpyW and StrCatW

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17900 Your paranoid android. === W2KPROSP4 (32 bit string) === string: unhandled exception c0000005 at 77C7F8A8

April 16, 2012

Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)

by Marcus Meissner

On Mon, Apr 16, 2012 at 11:53:00AM -0500, Andrew Eikum wrote: > On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote: > > Also initialize a "may be uninitialized" value the compiler sees. > > > > Not sure what this means. *num is initialized at the beginning of > alsa_enum_devices, which is always called from GetEndpointIDs. Seems > like a Coverity oversight. I'd either leave it as-is, or also remove > the *num=0 from alsa_enum_devices. It cannot handle two variables that track the same logic easily. So it cannot see "counter" and "content" variables that belong together. I marked it as FALSE now. Ciao, Marcus

April 16, 2012

Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)

by Andrew Eikum

On Mon, Apr 16, 2012 at 11:53:00AM -0500, Andrew Eikum wrote: > On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote: > > Also initialize a "may be uninitialized" value the compiler sees. > > Of course I quoted the wrong section of your mail :) > > Not sure what this means. *num is initialized at the beginning of > alsa_enum_devices, which is always called from GetEndpointIDs. Seems > like a Coverity oversight. I'd either leave it as-is, or also remove > the *num=0 from alsa_enum_devices. > > Andrew > > > Ciao, Marcus > > --- > > dlls/winealsa.drv/mmdevdrv.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > > index e3c1d15..d84bbb2 100644 > > --- a/dlls/winealsa.drv/mmdevdrv.c > > +++ b/dlls/winealsa.drv/mmdevdrv.c > > @@ -345,7 +345,7 @@ static WCHAR *construct_device_id(EDataFlow flow, const WCHAR *chunk1, const cha > > { > > WCHAR *ret; > > const WCHAR *prefix; > > - DWORD len_wchars = 0, chunk1_len, copied = 0, prefix_len; > > + DWORD len_wchars = 0, chunk1_len = 0, copied = 0, prefix_len; > > > > static const WCHAR dashW[] = {' ','-',' ',0}; > > static const size_t dashW_len = (sizeof(dashW) / sizeof(*dashW)) - 1; > > @@ -583,6 +583,7 @@ HRESULT WINAPI AUDDRV_GetEndpointIDs(EDataFlow flow, WCHAR ***ids, GUID **guids, > > > > TRACE("%d %p %p %p %p\n", flow, ids, guids, num, def_index); > > > > + *num = 0; > > *ids = NULL; > > *guids = NULL; > > > > -- > > 1.7.3.4 > > > > > > > >

April 16, 2012

Re: [PATCH] winealsa.drv: Init *num to 0 (Coverity)

by Andrew Eikum

On Mon, Apr 16, 2012 at 09:09:58AM +0200, Marcus Meissner wrote: > Also initialize a "may be uninitialized" value the compiler sees. > Not sure what this means. *num is initialized at the beginning of alsa_enum_devices, which is always called from GetEndpointIDs. Seems like a Coverity oversight. I'd either leave it as-is, or also remove the *num=0 from alsa_enum_devices. Andrew > Ciao, Marcus > --- > dlls/winealsa.drv/mmdevdrv.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index e3c1d15..d84bbb2 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -345,7 +345,7 @@ static WCHAR *construct_device_id(EDataFlow flow, const WCHAR *chunk1, const cha > { > WCHAR *ret; > const WCHAR *prefix; > - DWORD len_wchars = 0, chunk1_len, copied = 0, prefix_len; > + DWORD len_wchars = 0, chunk1_len = 0, copied = 0, prefix_len; > > static const WCHAR dashW[] = {' ','-',' ',0}; > static const size_t dashW_len = (sizeof(dashW) / sizeof(*dashW)) - 1; > @@ -583,6 +583,7 @@ HRESULT WINAPI AUDDRV_GetEndpointIDs(EDataFlow flow, WCHAR ***ids, GUID **guids, > > TRACE("%d %p %p %p %p\n", flow, ids, guids, num, def_index); > > + *num = 0; > *ids = NULL; > *guids = NULL; > > -- > 1.7.3.4 > > >

April 16, 2012

Re: msvcrt: Added more length modifiers in scanf function

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17893 Your paranoid android. === WNT4WSSP6 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234 === W2KPROSP4 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234 === WXPPROSP3 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234 === W2K3R2SESP2 (32 bit scanf) === scanf.c:144: Test failed: sprintf retuned 10 scanf.c:145: Test failed: got 1942892530, expected 12345678901234

April 16, 2012

Re: ws2_32: Fix hostent memory allocation

by Bruno Jesus

On Mon, Apr 16, 2012 at 10:17, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > That's not a good helper function, with all the optional parameters and > various behaviors. Also if you need a big documentation block like this > for a 5-line function it's a sign that something is wrong. Sorry, I didn't know it was bad to document small functions. So should I duplicate list_size creating list_count to get the number of items or should I simply loop and count the size and item count without using list_size in WS_dup_he? > -- > Alexandre Julliard > julliard(a)winehq.org Best wishes, Bruno

April 16, 2012

Re: WASAPI ISimpleAudioVolume::SetMasterVolume appears to not work

by Andrew Eikum

Hi Adam, On Sun, Apr 15, 2012 at 12:06:14AM +0100, adam smith wrote: > I've been trying to get WASAPI audio output working for our app as > Directsound output was very glitchy post the new audio stack. > Sorry to hear that. We do have a large sequence of patches just about ready to go into Wine which will improve directsound greatly, but they're not in quite yet. > All seems to work great with WASAPI however I need to able to set the > volume level independently for individual audio sessions / streams for > crossfading however I'm having problems controlling the volume levels of a > shared mode audio session / stream. specifically, > > ISimpleAudioVolume::SetMasterVolume ... returns success but does not > change the volume level though interestingly > Yes, this is a limitation of the ALSA and OSS drivers. You can see that <dlls/winealsa.drv/mmdevdrv.c:SimpleAudioVolume_SetMasterVolume> actually doesn't do anything. This is because ALSA and OSS don't support per-stream volume control. For example, if we set the volume on an ALSA device, it will actually affect the volume of _every_ stream that uses that ALSA device, which isn't what we want. > HRESULT hr; > hr=audioClient_->GetService(IID_ISimpleAudioVolume,(void**)&simpleAudioVolume_); > if (SUCCESS(hr)) > hr=simpleAudioVolume_->SetMute(TRUE,NULL); > > does work and mute the volume. > Yes, we have some logic to allow muting to work, by just setting the samples sent to ALSA to silence. Again, this is because muting the ALSA device would result in muting _every_ stream using that device. > Does anyone have any experience of these interfaces or know equivalent > interfaces to use instead > Sorry, Linux's audio systems just don't have the capabilities to let Wine do this. We would need to build a software mixer into Wine to do volume control, and we don't have that (yet). Andrew

April 16, 2012

Re: ws2_32: Fix hostent memory allocation

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > @@ -5546,24 +5546,70 @@ INT WINAPI WSAUnhookBlockingHook(void) > * pointers (via a template of some kind). > */ > > -static int list_size(char** l, int item_size) > +/*********************************************************************** > + * list_size (INTERNAL) > + * > + * Calculate the size of data and number of items from a list based on > + * a fixed item size or strings by using strlen. The source list must be > + * NULL terminated. > + * > + * PARAMS > + * l [I] Pointer to array of source items. > + * item_size [I] Fixed item size or zero if it's a string list. > + * size_sum [O] Pointer to where the sum of item bytes will be > + * stored. May be NULL if not required by the caller. > + * item_count [O] Pointer to where the number of items bytes will be > + * stored. May be NULL if not required by the caller. > + * > + * NOTES > + * When item_size is zero the byte sum will also count the NULL > + * terminator for each string. > + */ > +static void list_size(char** l, int item_size, int *size_sum, int *item_count) > { > - int i,j = 0; > - if(l) > - { for(i=0;l[i];i++) > - j += (item_size) ? item_size : strlen(l[i]) + 1; > - j += (i + 1) * sizeof(char*); } > - return j; > + int s, c, *sum = (size_sum ? size_sum : &s), *count = (item_count ? item_count : &c); > + *sum = *count = 0; > + if(l) > + { > + for(;l[*count];(*count)++) > + *sum += (item_size) ? item_size : strlen(l[*count]) + 1; > + } That's not a good helper function, with all the optional parameters and various behaviors. Also if you need a big documentation block like this for a 5-line function it's a sign that something is wrong. -- Alexandre Julliard julliard(a)winehq.org

April 16, 2012

Re: jscript: Make sure to jump out of switch before entering implicit default clausule

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17883 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found

April 16, 2012

Re: Testbot certificate has expired

by Jacek Caban

Hi Morten, On 04/15/12 14:59, Morten Rønne wrote: > Hi > > testbot.winehq.com certificate expired on 13-04-2012. So now the > wininet tests in dlls/wininet/tests/http.c are failing with an error > for me. > I can't determine if the fault are in the test or the function called > should handle the error case. > > The error message is: > err:wininet:NETCON_secure_connect SSL_connect failed: 12037 > http.c:2873: Test failed: HttpSendRequest failed: 12037 > wine: Unhandled page fault on read access to 0x00000008 at address > 0x68a876c5 (thread 0009), starting debugger... > Unhandled exception: page fault on read access to 0x00000008 in 32-bit > code (0x68a876c5). Ideally we should use https://test.winehq.org/ instead (and generally test.winehq.org for all tests) so that we'd have better control over test infrastructure. I've started moving things in this direction last year, but never had enough time to finish it. Cheers, Jacek

April 16, 2012

Re: gdi32: Add support for emulating bold faces of bitmap fonts.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > > > Don't we need to add some bytes if glyph_width % 32 == 0 ? > > > > Well, I didn't see in my tests a need for that. > > That may be because your tests are just looking at the font metrics > and not at the glyphs themselves... I have an application that actually needs that, so I'm "testing" the resulting glyphs by eyes, while font metrics get tested by the tests. -- Dmitry.

April 16, 2012

Re: msvcp90: Add codecvt ctors and dtors

by Piotr Caban

Hi, On 04/16/12 02:50, William Panlener wrote: > typedef struct { > + locale_facet facet; > + /* FIXME: type definition in standard but var here */ > + enum { ok, partial, error, noconv } result; > +} codecvt_base; This structure has incorrect size. It should not contain result variable. > +typedef struct { > + codecvt_base base; > + /* FIXME: incomplete struct definition */ > +} codecvt_char_char_mbstate; It's better to define whole structure. Also other structures are named differently, it would be probably better to name it codecvt_char. > +typedef struct { > + codecvt_base base; > + /* FIXME: incomplete struct definition */ > +} codecvt_short_char_mbstate; > + > +typedef struct { > + codecvt_base base; > + /* FIXME: incomplete struct definition */ > +} codecvt_wchar_char_mbstate; There's no reason to define separate structures for unsigned short and wchar_t variants of the class. Probably the only difference between this classes is typeinfo structure. > +/* FIXME: Potentially unused */ > +/* ?id@?$codecvt(a)DDH@std@@2V0locale(a)2@A */ > +locale_id codecvt_char_char_mbstate_id = {0}; I don't understand this comment. The id fields will be used by locale class. > +/* ??1codecvt_base(a)std@@UAE(a)XZ */ > +/* ??1codecvt_base(a)std@@UEAA(a)XZ */ > +DEFINE_THISCALL_WRAPPER(codecvt_base_dtor, 4) > +void __thiscall codecvt_base_dtor(codecvt_base *this) > +{ > + FIXME("(%p)\n stub!", this); > + TRACE("(%p)\n", this); > +} There's no need to use both FIXME and TRACE. > +/* ??1?$codecvt(a)DDH@std@@MAE(a)XZ */ > +/* ??1?$codecvt(a)DDH@std@@MEAA(a)XZ */ > +DEFINE_THISCALL_WRAPPER(codecvt_char_char_mbstate_dtor, 4) > +void __thiscall codecvt_char_char_mbstate_dtor(codecvt_char_char_mbstate *this) > +{ > + /*FIXME stub*/ > + codecvt_base_dtor(&this->base); > + TRACE("(%p)\n", this); > +} It's better to print a fixme message here. > +DEFINE_RTTI_DATA(codecvt_char_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor, NULL, NULL, " ?AV?$codecvt(a)DDH@std@@"); > +DEFINE_RTTI_DATA(codecvt_short_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor, NULL, NULL, " ?AV?$codecvt(a)GDH@std@@"); > +DEFINE_RTTI_DATA(codecvt_wchar_char_mbstate, 0, 1,&locale_facet_rtti_base_descriptor, NULL, NULL, ".?AV?$codecvt(a)_WDH@std@@"); The RTTI data for these structures is incorrect. > + __ASM_VTABLE(codecvt_base, ""/*FIXME*/); > + __ASM_VTABLE(codecvt_char_char_mbstate, ""/*FIXME*/); > + __ASM_VTABLE(codecvt_short_char_mbstate, ""/*FIXME*/); > + __ASM_VTABLE(codecvt_wchar_char_mbstate, ""/*FIXME*/); It's better to create correct virtual functions table. This may lead to some strange crashes.

April 16, 2012

Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug

by Roderick Colenbrander

On 4/16/12, Alexey Loukianov <mooroon2(a)mail.ru> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 16.04.2012 04:28, Vitaliy Margolen wrote: >> Of course it won't - they are binary blobs from Nvidia. Not much to see >> there. All you really looking for are time spent in that library. >> > > Vitaliy, I don't expect oprofile to find hidden COFF or DWARF 2 debug infos > inside nVIDIA binary blob, it's obvious that there are nothing like that > there > :-). > > What I was expecting to find in oprofile output is a libGL.so subdivision > like > may be seen in "objdump -T /usr/lib/libGL.so.295.40" output. Thinking a bit > more about it makes it clear that my expectations were wrong as the export > table doesn't have all the required info for oprofile to act as a poors man > substitute for real symbols map file (for example, it can't be determined > for > sure from exports table what are the actual proc boundaries for any given > exported symbol). > > What might be useful for profiling in this case is a "proxy" wrapper for > libGL > that sits between Wine and real libGL and collects call timing stats. A > wrapper of such kind wouldn't be as devastating to FPS as apitrace, and it > would provide a fine-grained picture on per-proc timing stats which are > extremely helpful when one is trying to catch a GPU driver bug. I have no > idea > if there's such a wrapper already implemented out in a wild. Something equivalent exists and is in Wine. When compiling wined3d compile it with -DUSE_WIN32_OPENGL to route all GL calls through wine's opengl32.dll. It may give some more clues. About all Nvidia driver calls end up in libGLcore.so where libGL.so is a thin wrapper. You likely won't see that much more, but it is easy to try. Roderick > > - -- > Best regards, > Alexey Loukianov mailto:mooroon2(a)mail.ru > System Engineer, Mob.:+7(926)218-1320 > *nix Specialist > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.16 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJPi20tAAoJEPB9BOdTkBULPo4IAKFYIbPvg0Znv6AOiZt+C2yV > +uiq1+FZcdeMedfGZrA8lelOvUEp9h8/wuDEmZ2YEW28+S/qkMA0EL0MaJY7hqZz > ac3vdt/wVxxDpwAm1Jjl0YjmzhZP4dE8fyB42Clh5+McIG7MvsO7sHfGmQk9Jbye > d+KvoOWbOFaB5fNrXr+lQMGqkNTSMas3TQS3KIVeiCFitDzXwDHoK7dGykeiJ340 > q0MxqRRa7XvGSZNtw9Q043ZeywaNMFD/k6tSUkIXwP/FlZsTBPHhr7M37h+gjt84 > 2w26KE7cncoUKl1l3w7WfUMN9/MgEKmtX5O0nsP0S8EBCdehfVhOlUcUI48Kkgk= > =Kkgh > -----END PGP SIGNATURE----- > > >

April 16, 2012

Re: gdi32: Add support for emulating bold faces of bitmap fonts.

by Huw Davies

On Mon, Apr 16, 2012 at 05:51:20PM +0900, Dmitry Timoshkov wrote: > Huw Davies <huw(a)codeweavers.com> wrote: > > > Don't we need to add some bytes if glyph_width % 32 == 0 ? > > Well, I didn't see in my tests a need for that. That may be because your tests are just looking at the font metrics and not at the glyphs themselves...

April 16, 2012

Re: gdi32: Add support for emulating bold faces of bitmap fonts.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > Don't we need to add some bytes if glyph_width % 32 == 0 ? Well, I didn't see in my tests a need for that. -- Dmitry.

April 16, 2012

Re: gdi32: Add support for emulating bold faces of bitmap fonts.

by Huw Davies

On Mon, Apr 16, 2012 at 04:37:39PM +0900, Dmitry Timoshkov wrote: > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 0a5d3c3..eb3f9b5 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -5669,12 +5669,27 @@ static inline BYTE get_max_level( UINT format ) > return 255; > } > > -static const BYTE masks[8] = {0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, 0x01}; > +static void emulate_bold_glyph(BYTE *buf, int pitch, int height) > +{ > + int x, y; > + BYTE *p = buf; > + > + for (y = 0; y < height; y++) > + { > + for (x = pitch - 1; x >= 0; x--) > + { > + p[x] |= p[x] >> 1; > + if (x > 0) p[x] |= p[x - 1] << 7; > + } > + p += pitch; > + } > +} > Don't we need to add some bytes if glyph_width % 32 == 0 ? Huw.

April 16, 2012

Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug

by Alexey Loukianov

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 16.04.2012 04:28, Vitaliy Margolen wrote: > Of course it won't - they are binary blobs from Nvidia. Not much to see > there. All you really looking for are time spent in that library. > Vitaliy, I don't expect oprofile to find hidden COFF or DWARF 2 debug infos inside nVIDIA binary blob, it's obvious that there are nothing like that there :-). What I was expecting to find in oprofile output is a libGL.so subdivision like may be seen in "objdump -T /usr/lib/libGL.so.295.40" output. Thinking a bit more about it makes it clear that my expectations were wrong as the export table doesn't have all the required info for oprofile to act as a poors man substitute for real symbols map file (for example, it can't be determined for sure from exports table what are the actual proc boundaries for any given exported symbol). What might be useful for profiling in this case is a "proxy" wrapper for libGL that sits between Wine and real libGL and collects call timing stats. A wrapper of such kind wouldn't be as devastating to FPS as apitrace, and it would provide a fine-grained picture on per-proc timing stats which are extremely helpful when one is trying to catch a GPU driver bug. I have no idea if there's such a wrapper already implemented out in a wild. - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPi20tAAoJEPB9BOdTkBULPo4IAKFYIbPvg0Znv6AOiZt+C2yV +uiq1+FZcdeMedfGZrA8lelOvUEp9h8/wuDEmZ2YEW28+S/qkMA0EL0MaJY7hqZz ac3vdt/wVxxDpwAm1Jjl0YjmzhZP4dE8fyB42Clh5+McIG7MvsO7sHfGmQk9Jbye d+KvoOWbOFaB5fNrXr+lQMGqkNTSMas3TQS3KIVeiCFitDzXwDHoK7dGykeiJ340 q0MxqRRa7XvGSZNtw9Q043ZeywaNMFD/k6tSUkIXwP/FlZsTBPHhr7M37h+gjt84 2w26KE7cncoUKl1l3w7WfUMN9/MgEKmtX5O0nsP0S8EBCdehfVhOlUcUI48Kkgk= =Kkgh -----END PGP SIGNATURE-----

April 16, 2012

Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug

by Vitaliy Margolen

On 04/15/2012 04:44 PM, Alexey Loukianov wrote: > With oprofile I hit another trouble - it seems that this tool is unable to > fetch symbols from libGL Of course it won't - they are binary blobs from Nvidia. Not much to see there. All you really looking for are time spent in that library. Vitaliy.

April 16, 2012

Re: Request for help/advice in investigation of one interesting "huge FPS regression" bug

by Alexey Loukianov

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 15.04.2012 21:50, Stefan Dösinger wrote: > your best bet would be using something like oprofile to find out which GL > calls show performance changes. Well, I had compiled/installed APITrace 3.0 and oprofile 0.9.7 on my system, but it seems that it'd be by the very least "problematic" to get any useful info from these. APITrace 3.0 works fine with Wine, but the performance hit is huge and resulting trace size seems to be non-manageable. Trace file containing two frames displayed at the game login screen is ~2GB in size, and non-surprisingly game performance is more like "one frame per twenty seconds". With oprofile I hit another trouble - it seems that this tool is unable to fetch symbols from libGL, at least all I get in reports related to libGL are simple references to /usr/lib/libGL.so.295.40, /usr/lib/libnvidia-glcore.so.295.40 and /usr/lib/tls/libnvidia-tls.so.295.40 without any details available on symbols that are internal to this libs. It might be me misusing oprofile although, as currently it is the first time ever I'm trying to use it to do profiling tasks. - -- Best regards, Alexey Loukianov mailto:mooroon2(a)mail.ru System Engineer, Mob.:+7(926)218-1320 *nix Specialist -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPi09CAAoJEPB9BOdTkBULLOQIAKEYcBV7xB3ii6BC8TNT7dzT YLnwGBtERPRpm+n3xfRzNmm2JCmDVMNQtZAZ8xxyMe2rksQW2Pu2v4R86QfdLZ2k NSGJm83lykH3VExz79dBkgHnBCNk129UIC7nfSLkDAWfZUvxuvQb1+flWtR/N224 98k2NNyxoZ09aiI3hwvJL7ckRtk1tOZaoObTteVxgfZBIZ7o5LXiILhwlgkbuJbZ hy9xIEQdCTXovpnQnqq3O4aPCI6ikIlUe0ySWtEo+5HtEKnA7u0/5OFEFKOEol/1 WnIzH0GVf4SnLOBy59NjIsX8ho3/q4/sz3TOHoiOs/ng/tjzAZMQmF/4Bk8k4+4= =Kyxl -----END PGP SIGNATURE-----

April 15, 2012