Re: po: Arabic full translated wine. (try2)

[Yaron Shahrabani]

Non critical changes but take a look if you like:
 #: comdlg32.rc:186 comdlg32.rc:141
-#, fuzzy
 msgid Save As
 msgstr احفظ ك‍...

Redundant Elipsis.

 #: comdlg32.rc:202
-#, fuzzy
 msgid Selection
-msgstr اختر الكل\tCtrl+A
+msgstr الاختيار

 #: comdlg32.rc:203
-#, fuzzy
 msgid Pages
-msgstr صفحة p
+msgstr صفحات

 #: comdlg32.rc:206 comdlg32.rc:228
-#, fuzzy
 msgid Setup
-msgstr إعداد الصفحة
+msgstr إعداد
No accelerator () sign.

 #: comdlg32.rc:207
 msgid From:
-msgstr 
+msgstr من

 #: comdlg32.rc:208
 msgid To:
-msgstr 
+msgstr إلى

No semicolon at the end.


 #: comdlg32.rc:211
-#, fuzzy
 msgid Print to File
-msgstr ملفات النصوص (*.txt)
+msgstr اطبع إلى ملف

 #: comdlg32.rc:268
 msgid Script:
-msgstr 
+msgstr ترميز

No accelerator sign.

 #: comdlg32.rc:281 comdlg32.rc:304
 msgid Color |  Solid
-msgstr 
+msgstr اللون |  جامد

No need to add اللون |‏ before the  جامد part.

There might be more.

Anyways great job!


Kind regards,


Yaron Shahrabani

Hebrew translator



On Sun, Jun 30, 2013 at 6:27 AM, مصعب الزعبي moc...@hotmail.com wrote:

 ---

  po/ar.po

Re: [wbemprox] Patches for adding currentclockspeed in record_processor

[Hans Leidekker]

On Mon, 2013-07-01 at 08:56 +0900, Rosen Diankov wrote:

 diff -ru wine-1.6-rc3-old/dlls/wbemprox/builtin.c 
 wine-1.6-rc3/dlls/wbemprox/builtin.c
 --- wine-1.6-rc3-old/dlls/wbemprox/builtin.c2013-06-22 03:24:01.0 
 +0900
 +++ wine-1.6-rc3/dlls/wbemprox/builtin.c2013-06-27 23:04:20.170154454 
 +0900

Please use git to generate patches.

 @@ -168,6 +168,8 @@
  {'M','a','n','u','f','a','c','t','u','r','e','r',0};
  static const WCHAR prop_maxclockspeedW[] =
  {'M','a','x','C','l','o','c','k','S','p','e','e','d',0};
 +static const WCHAR prop_currentclockspeedW[] =
 +{'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0};

Please keep properties sorted here and below.

  static const WCHAR prop_memberW[] =
  {'M','e','m','b','e','r',0};
  static const WCHAR prop_methodW[] =
 @@ -381,6 +383,7 @@
  { prop_familyW,   CIM_UINT16, VT_I4 },
  { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC },
  { prop_maxclockspeedW,CIM_UINT32, VT_I4 },
 +{ prop_currentclockspeedW,CIM_UINT32, VT_I4 },
  { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC },
  { prop_numcoresW, CIM_UINT32, VT_I4 },
  { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 },
 @@ -633,6 +636,7 @@
  UINT16   family;
  const WCHAR *manufacturer;
  UINT32   maxclockspeed;
 +UINT32   currentclockspeed;
  const WCHAR *name;
  UINT32   num_cores;
  UINT32   num_logical_processors;
 @@ -1690,7 +1694,33 @@
  regs_to_str( regs, 16, name + 32 );
  }
  }
 -static UINT get_processor_maxclockspeed( void )
 +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT* 
 currentclockspeed )
 +{
 +PROCESSOR_POWER_INFORMATION *info;
 +UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION);
 +NTSTATUS status;
 +
 +if ((info = heap_alloc( size )))
 +{
 +status = NtPowerInformation( ProcessorInformation, NULL, 0, info, 
 size );
 +if (!status)
 +{
 +*maxclockspeed = info[0].MaxMhz;
 +*currentclockspeed = info[0].CurrentMhz;
 +}
 +heap_free( info );
 +}
 +if( !!maxclockspeed )
 +{
 +*maxclockspeed = 1000;
 +}
 +if( !!currentclockspeed )
 +{
 +*currentclockspeed = 1000;
 +}
 +}

You probably didn't mean to query the clock speeds and then overwrite them with 
static values.
NULL checks are not needed in helpers like this.

 +/*static UINT get_processor_maxclockspeed( void )
  {
  PROCESSOR_POWER_INFORMATION *info;
  UINT ret = 1000, size = get_processor_count() * 
 sizeof(PROCESSOR_POWER_INFORMATION);
 @@ -1703,7 +1733,8 @@
  heap_free( info );
  }
  return ret;
 -}
 +}*/

Don't comment out code. Remove it.

  static const WCHAR *get_osarchitecture(void)
  {
  SYSTEM_INFO info;
 @@ -1717,7 +1748,7 @@
  static const WCHAR fmtW[] = {'C','P','U','%','u',0};
  WCHAR device_id[14], processor_id[17], manufacturer[13], name[49] = {0};
  struct record_processor *rec;
 -UINT i, offset = 0, maxclockspeed, num_cores, num_logical_processors, 
 count = get_processor_count();
 +UINT i, offset = 0, maxclockspeed = 0, currentclockspeed = 0, num_cores, 
 num_logical_processors, count = get_processor_count();
  enum fill_status status = FILL_STATUS_UNFILTERED;
  
  if (!resize_table( table, count, sizeof(*rec) )) return 
 FILL_STATUS_FAILED;
 @@ -1726,7 +1757,7 @@
  get_processor_manufacturer( manufacturer );
  get_processor_name( name );
  
 -maxclockspeed = get_processor_maxclockspeed();
 +get_processor_clockspeeds(maxclockspeed, currentclockspeed);
  num_logical_processors = get_logical_processor_count( num_cores ) / 
 count;
  num_cores /= count;

You're not using currentclockspeed.

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Peter Rosin]

On 2013-06-29 18:33, Alan W. Irwin wrote:
 Those have been mentioned before here, and I have looked at them.
 Cygwin is a very large collection of software so the number of bugs
 that are reported does not seem excessive to me, and for my personal
 needs (building and testing software on the Cygwin platform) I will
 only be using a subset of Cygwin so I may avoid encountering
 some of these bugs. Furthermore, some of these bugs (e.g.,
 problems resizing a GUI) are not showstoppers, and most of them are
 quite old. At the same time the latest Wine is far superior to
 Wine-1.4 so some of those bugs may have just disappeared.  I hope to
 find out about the actual status of Cygwin on Wine
 bugs once I can get setup.exe to work on Wine.

I would like to point out that it seems that the current bug does not
appear to be *in* setup.exe, but rather occurs when setup.exe runs
a bash post-install script, where the bash.exe that interprets the
script depends on cygwin1.dll. If my analysis is correct, the bug
would occur also when duplicating the actions of setup.exe manually.
You would have to also duplicate the actions of all post-install
scripts, which is certainly more work and more error-prone than
duplicating the download and unpacking of a few tarballs.

Cheers,
Peter

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 06:13+0100 Hin-Tak Leung wrote:

[...]In terms of relative importance, consider that mingw (both native and cross) GNU toolchain works well, 
the toolchain part of cygwin is hardly a priority.


Once again you are implying the MinGW GNU toolchain is better than the
Cygwin GNU toolchain without mention of any bug reports from you to
Cygwin to back up that assertion.  Your constant repetition of this
theme made me curious so I looked you up on the web, and it appears
you are a MinGW developer.

If you really are a MinGW developer, I hope your negative attitude
toward the Cygwin toolchain is not typical of such developers.  After
all, even though the Windows GNU toolchain code bases have diverged
between the two groups of developers, there is still a common interest
between MinGW and Cygwin developers regarding getting the GNU
toolchain to work properly on Windows.

You certainly have the right to express your opinion about the Cygwin
toolchain here, and you _might_ even be correct, but I am concerned
you are biased since you appear to be broadcasting anecdotal evidence
without sending in bug reports to Cygwin concerning what you have
found.

And now to get back on topic again, thanks, André, for that reference
to http://wiki.winehq.org/CygwinSupport.  The two points there are
worth repeating:

For Wine, the upside would be:
  * a very good test suite
  * a much more solid implementation of the fundamental Win32 APIs

These same points can be made about MinGW/MSYS and my work on building
software (whose build is configured by my build_projects project) on
Wine with that toolchain.  And that work has already contributed to 3
Wine fixes (two of which were regressions introduced in the 1.5.x
series).

However, it should be emphasized that Cygwin is a very much bigger
free software project than MinGW/MSYS.  So it provides a much more
comprehensive and rigourous test of Wine than MinGW/MSYS, and this
will be the case for the forseeable future.  The number of software
projects whose builds are configured by build_projects is growing, but
that number it is still very much smaller than the list of software
builds that are included in the Cygwin distribution.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

[PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

Main changes from v6:
1) Fix LOCK_DELETE mandatory lock detection for O_DENYDELETE opens.
2) Add ESHAREDENIED error code definition for alpha, mips, parisc and sparc 
arches.
3) Remove code changes in do_last function if sharelocks are disabled.

Main changes from v5:
1) O_DENYDELETE is now supported by VFS.
2) ESHAREDENIED erro code is introduced to be returned on sharelock conflicts.
3) forcemand dependancy is removed. CIFS module detects if it should use 
NTCreateAndX command according to existence of O_DENY flags.
4) Term 'deny lock' is replaced by 'sharelock' (function names, code comments, 
patch descriptions).

Main changes from v4:
1) deny_lock_file uses FS_DOES_SHARELOCK flag from fs_flags to determine 
whether to use VFS locks or not.
2) Make nfs code return -EBUSY for share conflicts (was -EACCESS).

Main changes from v3
1) O_DENYMAND is removed, sharelock mount option is introduced.
2) Patch fcntl.h and VFS patches are united into one.
3) flock/LOCK_MAND is disabled for sharelock mounts.

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can 
be used by any application that needs share reservations to organize a file 
access. VFS already has some sort of this capability - now it's done through 
flock/LOCK_MAND mechanism, but that approach is non-atomic. This patchset 
builds new capabilities on top of the existing one but doesn't bring any 
changes into the flock call semantic.

These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and 
Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This 
will help when e.g. Samba and NFS server share the same directory for Windows 
and Linux users or Wine applications use Samba/NFS share to access the same 
data from different clients.

According to the previous discussions the most problematic question is how to 
prevent situations like DoS attacks where e.g /lib/liba.so file can be open 
with DENYREAD, or smth like this. That's why extra mount option 'sharelock' is 
added for switching on/off O_DENY* flags processing. It allows us to avoid use 
of these flags on critical places (like /, /lib) and turn them on if we really 
want it proccessed that way.

The patchset introduces 3 new flags:
O_DENYREAD - to prevent other opens with read access,
O_DENYWRITE - to prevent other opens with write access,
O_DENYDELETE - to prevent delete operations (this flag can't be implemented for 
NFS due to the protocol restrictions).

The patchset avoids data races problem on newely created files: open with 
O_CREAT can return new -ESHAREDENIED error code for a successfully created file 
if this files was locked with a sharelock by another task. Also, it turns off 
flock/LOCK_MAND capability for mounts with 'sharelock' option. This lets us not 
mix one share reservation approach with another.

The #1 and #2 patches add flags to fcntl and implements VFS part. The patches 
#3 and #4 are related to CIFS-specific changes, #5 and #6 describe NFS and NFSD 
parts, #7 turns off flock/LOCK_MAND for mounts with 'sharelock' option.

The preliminary patch for Samba that replaces the existing use of 
flock/LOCK_MAND mechanism with O_DENY* flags:
http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=173070262b7f29134ad6b2e49a760017c11aec4a

The future part of open man page patch:

-
O_DENYREAD, O_DENYWRIYE, O_DENYDELETE - used to inforce a mandatory share 
reservation scheme of the file access. If these flag is passed, the open fails 
with -ESHAREDENIED in following cases:
1) if O_DENYREAD flag is specified and there is another open with READ access 
to the file;
2) if O_DENYWRITE flag is specified and there is another open with WRITE access 
to the file;
3) if READ access is requested and there is another open with O_DENYREAD flags;
4) if WRITE access is requested and there is another open with O_DENYWRITE 
flags.

If O_DENYDELETE flag is specified and the open succeded, any further unlink 
operation will fail with -ESHAREDENIED untill this open is closed. Now this 
flag is processed by VFS and CIFS filesystem.

This mechanism is done through flocks. If O_DENY* flags are specified, flock 
syscall is processed after the open. The share modes are translated into flock 
according the following rules:
1) !O_DENYREAD   - LOCK_READ   | LOCK_MAND
2) !O_DENYWRITE  - LOCK_WRITE  | LOCK_MAND
3) !O_DENYDELETE - LOCK_DELETE | LOCK_MAND
---

Pavel Shilovsky (7):
  VFS: Introduce new O_DENY* open flags
  VFS: Add O_DENYDELETE support for VFS
  CIFS: Add share_access parm to open request
  CIFS: Add O_DENY* open flags support
  NFSv4: Add O_DENY* open flags support
  NFSD: Pass share reservations flags to VFS
  locks: Disable LOCK_MAND support for MS_SHARELOCK mounts

 arch/alpha/include/uapi/asm/errno.h  |   2 +
 arch/mips/include/uapi/asm/errno.h   |   2 +
 arch/parisc/include/uapi/asm/errno.h |   2 +
 arch/sparc/include/uapi/asm/errno.h  |   2 +
 fs/cifs/cifsacl.c|   8 +-
 

[PATCH v7 1/7] VFS: Introduce new O_DENY* open flags

[Pavel Shilovsky]

This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename.

Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules as well as Samba and
NFS file servers that export the same directory for Windows clients,
or Wine applications that access the same files simultaneously.

These flags are only take affect for opens on mounts with new sharelock
option. They are translated to flock's flags:

!O_DENYREAD  - LOCK_READ  | LOCK_MAND
!O_DENYWRITE - LOCK_WRITE | LOCK_MAND

and set through flock_lock_file on a file. If the file can't be locked
due conflicts with another open with O_DENY* flags, a new -ESHAREDENIED
error code is returned.

Create codepath is slightly changed to prevent data races on newly
created files: when open with O_CREAT can return -ESHAREDENIED error
for successfully created files due to a sharelock set by another task.

Temporary disable O_DENYDELETE support - will enable it in further
patches.

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 arch/alpha/include/uapi/asm/errno.h  |  2 +
 arch/mips/include/uapi/asm/errno.h   |  2 +
 arch/parisc/include/uapi/asm/errno.h |  2 +
 arch/sparc/include/uapi/asm/errno.h  |  2 +
 fs/fcntl.c   |  5 +-
 fs/locks.c   | 97 +---
 fs/namei.c   | 53 +++-
 fs/proc_namespace.c  |  1 +
 include/linux/fs.h   |  7 +++
 include/uapi/asm-generic/errno.h |  2 +
 include/uapi/asm-generic/fcntl.h | 11 
 include/uapi/linux/fs.h  |  1 +
 12 files changed, 175 insertions(+), 10 deletions(-)

diff --git a/arch/alpha/include/uapi/asm/errno.h 
b/arch/alpha/include/uapi/asm/errno.h
index e5f29ca..f51b81b 100644
--- a/arch/alpha/include/uapi/asm/errno.h
+++ b/arch/alpha/include/uapi/asm/errno.h
@@ -124,4 +124,6 @@
 
 #define EHWPOISON  139 /* Memory page has hardware error */
 
+#define ESHAREDENIED   140 /* File is locked with a sharelock */
+
 #endif
diff --git a/arch/mips/include/uapi/asm/errno.h 
b/arch/mips/include/uapi/asm/errno.h
index 31575e2f..dda1c73 100644
--- a/arch/mips/include/uapi/asm/errno.h
+++ b/arch/mips/include/uapi/asm/errno.h
@@ -123,6 +123,8 @@
 
 #define EHWPOISON  168 /* Memory page has hardware error */
 
+#define ESHAREDENIED   169 /* File is locked with a sharelock */
+
 #define EDQUOT 1133/* Quota exceeded */
 
 
diff --git a/arch/parisc/include/uapi/asm/errno.h 
b/arch/parisc/include/uapi/asm/errno.h
index 135ad60..bda01d5 100644
--- a/arch/parisc/include/uapi/asm/errno.h
+++ b/arch/parisc/include/uapi/asm/errno.h
@@ -124,4 +124,6 @@
 
 #define EHWPOISON  257 /* Memory page has hardware error */
 
+#define ESHAREDENIED   258 /* File is locked with a sharelock */
+
 #endif
diff --git a/arch/sparc/include/uapi/asm/errno.h 
b/arch/sparc/include/uapi/asm/errno.h
index c351aba..836eded 100644
--- a/arch/sparc/include/uapi/asm/errno.h
+++ b/arch/sparc/include/uapi/asm/errno.h
@@ -114,4 +114,6 @@
 
 #define EHWPOISON  135 /* Memory page has hardware error */
 
+#define ESHAREDENIED   136 /* File is locked with a sharelock */
+
 #endif
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 6599222..a1eee47 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -730,14 +730,15 @@ static int __init fcntl_init(void)
 * Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY
 * is defined as O_NONBLOCK on some platforms and not on others.
 */
-   BUILD_BUG_ON(19 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
+   BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32(
O_RDONLY| O_WRONLY  | O_RDWR|
O_CREAT | O_EXCL| O_NOCTTY  |
O_TRUNC | O_APPEND  | /* O_NONBLOCK | */
__O_SYNC| O_DSYNC   | FASYNC|
O_DIRECT| O_LARGEFILE   | O_DIRECTORY   |
O_NOFOLLOW  | O_NOATIME | O_CLOEXEC |
-   __FMODE_EXEC| O_PATH
+   __FMODE_EXEC| O_PATH| O_DENYREAD|
+   O_DENYWRITE | O_DENYDELETE
));
 
fasync_cache = kmem_cache_create(fasync_cache,
diff --git a/fs/locks.c b/fs/locks.c
index cb424a4..dbc5557 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -605,20 +605,73 @@ static int posix_locks_conflict(struct file_lock 
*caller_fl, struct file_lock *s
return (locks_conflict(caller_fl, sys_fl));
 }
 
-/* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
- * checking before calling the locks_conflict().
+static unsigned int
+deny_flags_to_cmd(unsigned int flags)
+{
+   unsigned int cmd = LOCK_MAND;
+
+   if (!(flags  O_DENYREAD))
+   cmd |= LOCK_READ;
+   

[PATCH v7 2/7] VFS: Add O_DENYDELETE support for VFS

[Pavel Shilovsky]

Introduce new LOCK_DELETE flock flag that is suggested to be used
internally only to map O_DENYDELETE open flag:

!O_DENYDELETE - LOCK_DELETE | LOCK_MAND.

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 fs/locks.c   | 55 +---
 fs/namei.c   |  3 +++
 include/linux/fs.h   |  6 +
 include/uapi/asm-generic/fcntl.h |  1 +
 4 files changed, 56 insertions(+), 9 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index dbc5557..c2fa136 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -269,7 +269,7 @@ EXPORT_SYMBOL(locks_copy_lock);
 
 static inline int flock_translate_cmd(int cmd) {
if (cmd  LOCK_MAND)
-   return cmd  (LOCK_MAND | LOCK_RW);
+   return cmd  (LOCK_MAND | LOCK_RW | LOCK_DELETE);
switch (cmd) {
case LOCK_SH:
return F_RDLCK;
@@ -614,6 +614,8 @@ deny_flags_to_cmd(unsigned int flags)
cmd |= LOCK_READ;
if (!(flags  O_DENYWRITE))
cmd |= LOCK_WRITE;
+   if (!(flags  O_DENYDELETE))
+   cmd |= LOCK_DELETE;
 
return cmd;
 }
@@ -836,6 +838,33 @@ out:
return error;
 }
 
+int
+sharelock_may_delete(struct dentry *dentry)
+{
+   struct file_lock **before;
+   int rc = 0;
+
+   if (!IS_SHARELOCK(dentry-d_inode))
+   return rc;
+
+   lock_flocks();
+   for_each_lock(dentry-d_inode, before) {
+   struct file_lock *fl = *before;
+   if (IS_POSIX(fl))
+   break;
+   if (IS_LEASE(fl))
+   continue;
+   if (!(fl-fl_type  LOCK_MAND))
+   continue;
+   if (fl-fl_type  LOCK_DELETE)
+   continue;
+   rc = 1;
+   break;
+   }
+   unlock_flocks();
+   return rc;
+}
+
 /*
  * Determine if a file is allowed to be opened with specified access and share
  * modes. Lock the file and return 0 if checks passed, otherwise return
@@ -850,10 +879,6 @@ sharelock_lock_file(struct file *filp)
if (!IS_SHARELOCK(filp-f_path.dentry-d_inode))
return error;
 
-   /* Disable O_DENYDELETE support for now */
-   if (filp-f_flags  O_DENYDELETE)
-   return -EINVAL;
-
error = flock_make_lock(filp, lock, deny_flags_to_cmd(filp-f_flags));
if (error)
return error;
@@ -1717,6 +1742,12 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, 
cmd)
if (!f.file)
goto out;
 
+   /* LOCK_DELETE is defined to be translated from O_DENYDELETE only */
+   if (cmd  LOCK_DELETE) {
+   error = -EINVAL;
+   goto out;
+   }
+
can_sleep = !(cmd  LOCK_NB);
cmd = ~LOCK_NB;
unlock = (cmd == LOCK_UN);
@@ -2261,10 +2292,16 @@ static void lock_get_status(struct seq_file *f, struct 
file_lock *fl,
seq_printf(f, UNKNOWN UNKNOWN  );
}
if (fl-fl_type  LOCK_MAND) {
-   seq_printf(f, %s ,
-  (fl-fl_type  LOCK_READ)
-  ? (fl-fl_type  LOCK_WRITE) ? RW: READ 
-  : (fl-fl_type  LOCK_WRITE) ? WRITE : NONE 
);
+   if (fl-fl_type  LOCK_DELETE)
+   seq_printf(f, %s ,
+   (fl-fl_type  LOCK_READ) ?
+   (fl-fl_type  LOCK_WRITE) ? RWDEL : RDDEL :
+   (fl-fl_type  LOCK_WRITE) ? WRDEL : DEL  );
+   else
+   seq_printf(f, %s ,
+   (fl-fl_type  LOCK_READ) ?
+   (fl-fl_type  LOCK_WRITE) ? RW: READ  :
+   (fl-fl_type  LOCK_WRITE) ? WRITE : NONE );
} else {
seq_printf(f, %s ,
   (lease_breaking(fl))
diff --git a/fs/namei.c b/fs/namei.c
index 7f6edb9..8aaffd4 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2220,6 +2220,7 @@ static inline int check_sticky(struct inode *dir, struct 
inode *inode)
  *  9. We can't remove a root or mountpoint.
  * 10. We don't allow removal of NFS sillyrenamed files; it's handled by
  * nfs_async_unlink().
+ * 11. We can't do it if victim is locked by O_DENYDELETE sharelock.
  */
 static int may_delete(struct inode *dir,struct dentry *victim,int isdir)
 {
@@ -2250,6 +2251,8 @@ static int may_delete(struct inode *dir,struct dentry 
*victim,int isdir)
return -ENOENT;
if (victim-d_flags  DCACHE_NFSFS_RENAMED)
return -EBUSY;
+   if (sharelock_may_delete(victim))
+   return -ESHAREDENIED;
return 0;
 }
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 774be38..3247fb4 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1006,6 +1006,7 @@ extern int lock_may_read(struct inode *, loff_t start, 

[PATCH v7 3/7] CIFS: Add share_access parm to open request

[Pavel Shilovsky]

and simplify CIFSSMBOpen params.

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 fs/cifs/cifsacl.c   |  8 
 fs/cifs/cifsglob.h  |  2 +-
 fs/cifs/cifsproto.h |  8 
 fs/cifs/cifssmb.c   | 50 +++---
 fs/cifs/dir.c   | 12 ++--
 fs/cifs/file.c  | 10 ++
 fs/cifs/inode.c | 16 ++--
 fs/cifs/link.c  | 25 -
 fs/cifs/readdir.c   |  5 ++---
 fs/cifs/smb1ops.c   | 16 +++-
 fs/cifs/smb2file.c  | 10 +-
 fs/cifs/smb2inode.c |  4 ++--
 fs/cifs/smb2ops.c   | 10 ++
 fs/cifs/smb2pdu.c   |  6 +++---
 fs/cifs/smb2proto.h | 14 --
 15 files changed, 95 insertions(+), 101 deletions(-)

diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c
index f1e3f25..56bdae2 100644
--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -908,8 +908,8 @@ static struct cifs_ntsd *get_cifs_acl_by_path(struct 
cifs_sb_info *cifs_sb,
create_options |= CREATE_OPEN_BACKUP_INTENT;
 
rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, READ_CONTROL,
-   create_options, fid, oplock, NULL, cifs_sb-local_nls,
-   cifs_sb-mnt_cifs_flags  CIFS_MOUNT_MAP_SPECIAL_CHR);
+   FILE_SHARE_ALL, create_options, fid, oplock,
+   NULL, cifs_sb);
if (!rc) {
rc = CIFSSMBGetCIFSACL(xid, tcon, fid, pntsd, pacllen);
CIFSSMBClose(xid, tcon, fid);
@@ -969,8 +969,8 @@ int set_cifs_acl(struct cifs_ntsd *pnntsd, __u32 acllen,
access_flags = WRITE_DAC;
 
rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, access_flags,
-   create_options, fid, oplock, NULL, cifs_sb-local_nls,
-   cifs_sb-mnt_cifs_flags  CIFS_MOUNT_MAP_SPECIAL_CHR);
+   FILE_SHARE_ALL, create_options, fid, oplock,
+   NULL, cifs_sb);
if (rc) {
cERROR(1, Unable to open file to set ACL);
goto out;
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index 4f07f6f..80af61d 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -310,7 +310,7 @@ struct smb_version_operations {
   struct cifs_sb_info *);
/* open a file for non-posix mounts */
int (*open)(const unsigned int, struct cifs_tcon *, const char *, int,
-   int, int, struct cifs_fid *, __u32 *, FILE_ALL_INFO *,
+   int, int, int, struct cifs_fid *, __u32 *, FILE_ALL_INFO *,
struct cifs_sb_info *);
/* set fid protocol-specific info */
void (*set_fid)(struct cifsFileInfo *, struct cifs_fid *, __u32);
diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h
index f450f06..d285b81 100644
--- a/fs/cifs/cifsproto.h
+++ b/fs/cifs/cifsproto.h
@@ -362,10 +362,10 @@ extern int CIFSSMBQueryReparseLinkInfo(const unsigned int 
xid,
const struct nls_table *nls_codepage);
 #endif /* temporarily unused until cifs_symlink fixed */
 extern int CIFSSMBOpen(const unsigned int xid, struct cifs_tcon *tcon,
-   const char *fileName, const int disposition,
-   const int access_flags, const int omode,
-   __u16 *netfid, int *pOplock, FILE_ALL_INFO *,
-   const struct nls_table *nls_codepage, int remap);
+   const char *file_name, const int disposition,
+   const int desired_access, const int share_access,
+   const int omode, __u16 *netfid, int *oplock,
+   FILE_ALL_INFO *, struct cifs_sb_info *);
 extern int SMBLegacyOpen(const unsigned int xid, struct cifs_tcon *tcon,
const char *fileName, const int disposition,
const int access_flags, const int omode,
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index 8e2e799..c857b02 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -1289,10 +1289,10 @@ OldOpenRetry:
 
 int
 CIFSSMBOpen(const unsigned int xid, struct cifs_tcon *tcon,
-   const char *fileName, const int openDisposition,
-   const int access_flags, const int create_options, __u16 *netfid,
-   int *pOplock, FILE_ALL_INFO *pfile_info,
-   const struct nls_table *nls_codepage, int remap)
+   const char *file_name, const int disposition,
+   const int desired_access, const int share_access,
+   const int create_options, __u16 *netfid, int *oplock,
+   FILE_ALL_INFO *file_info, struct cifs_sb_info *cifs_sb)
 {
int rc = -EACCES;
OPEN_REQ *pSMB = NULL;
@@ -1300,6 +1300,8 @@ CIFSSMBOpen(const unsigned int xid, struct cifs_tcon 
*tcon,
int bytes_returned;
int name_len;
__u16 count;
+   struct nls_table *nls_codepage = cifs_sb-local_nls;
+   int remap = cifs_sb-mnt_cifs_flags  

[PATCH v7 4/7] CIFS: Add O_DENY* open flags support

[Pavel Shilovsky]

Construct share_access value from O_DENY* flags and send it to
the server. Use NTCreateAndX command rather than Trans2
all the time we have any of O_DENY* flags regardless of unix
extensions support. Also change smb error mapping of
NT_STATUS_SHARING_VIOLATION to -ESHAREDENIED.

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 fs/cifs/cifsfs.c   |  2 +-
 fs/cifs/cifsglob.h | 16 +++-
 fs/cifs/dir.c  |  4 
 fs/cifs/file.c | 15 +--
 fs/cifs/inode.c|  5 +++--
 fs/cifs/netmisc.c  |  2 +-
 fs/cifs/smb2maperror.c |  2 +-
 fs/locks.c | 11 ++-
 include/linux/fs.h |  1 +
 9 files changed, 49 insertions(+), 9 deletions(-)

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index 345fc89..92bd685 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -799,7 +799,7 @@ struct file_system_type cifs_fs_type = {
.name = cifs,
.mount = cifs_do_mount,
.kill_sb = cifs_kill_sb,
-   /*  .fs_flags */
+   .fs_flags = FS_DOES_SHARELOCK,
 };
 MODULE_ALIAS_FS(cifs);
 const struct inode_operations cifs_dir_inode_ops = {
diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index 80af61d..85703f6 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -465,7 +465,7 @@ struct smb_vol {
 CIFS_MOUNT_CIFS_BACKUPUID | CIFS_MOUNT_CIFS_BACKUPGID)
 
 #define CIFS_MS_MASK (MS_RDONLY | MS_MANDLOCK | MS_NOEXEC | MS_NOSUID | \
- MS_NODEV | MS_SYNCHRONOUS)
+ MS_NODEV | MS_SYNCHRONOUS | MS_SHARELOCK)
 
 struct cifs_mnt_data {
struct cifs_sb_info *cifs_sb;
@@ -947,6 +947,20 @@ struct cifsFileInfo {
struct work_struct oplock_break; /* work for oplock breaks */
 };
 
+static inline int
+cifs_get_share_flags(unsigned int flags)
+{
+   int share_access = 0;
+
+   if (!(flags  O_DENYREAD))
+   share_access |= FILE_SHARE_READ;
+   if (!(flags  O_DENYWRITE))
+   share_access |= FILE_SHARE_WRITE;
+   if (!(flags  O_DENYDELETE))
+   share_access |= FILE_SHARE_DELETE;
+   return share_access;
+}
+
 struct cifs_io_parms {
__u16 netfid;
 #ifdef CONFIG_CIFS_SMB2
diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c
index e5f6723..c03ad8c 100644
--- a/fs/cifs/dir.c
+++ b/fs/cifs/dir.c
@@ -216,7 +216,11 @@ cifs_do_create(struct inode *inode, struct dentry 
*direntry, unsigned int xid,
goto out;
}
 
+   if (IS_SHARELOCK(inode))
+   share_access = cifs_get_share_flags(oflags);
+
if (tcon-unix_ext  cap_unix(tcon-ses)  !tcon-broken_posix_open 
+   (share_access == FILE_SHARE_ALL) 
(CIFS_UNIX_POSIX_PATH_OPS_CAP 
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
rc = cifs_posix_open(full_path, newinode, inode-i_sb, mode,
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 7631b0c..febf807 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -216,6 +216,8 @@ cifs_nt_open(char *full_path, struct inode *inode, struct 
cifs_sb_info *cifs_sb,
  */
 
disposition = cifs_get_disposition(f_flags);
+   if (IS_SHARELOCK(inode))
+   share_access = cifs_get_share_flags(f_flags);
 
/* BB pass O_SYNC flag through on file attributes .. BB */
 
@@ -428,6 +430,7 @@ int cifs_open(struct inode *inode, struct file *file)
int rc = -EACCES;
unsigned int xid;
__u32 oplock;
+   int share_access = FILE_SHARE_ALL;
struct cifs_sb_info *cifs_sb;
struct TCP_Server_Info *server;
struct cifs_tcon *tcon;
@@ -463,8 +466,12 @@ int cifs_open(struct inode *inode, struct file *file)
else
oplock = 0;
 
-   if (!tcon-broken_posix_open  tcon-unix_ext 
-   cap_unix(tcon-ses)  (CIFS_UNIX_POSIX_PATH_OPS_CAP 
+   if (IS_SHARELOCK(inode))
+   share_access = cifs_get_share_flags(file-f_flags);
+
+   if (!tcon-broken_posix_open  tcon-unix_ext  cap_unix(tcon-ses) 
+   (share_access == FILE_SHARE_ALL) 
+   (CIFS_UNIX_POSIX_PATH_OPS_CAP 
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
/* can not refresh inode info since size could be stale */
rc = cifs_posix_open(full_path, inode, inode-i_sb,
@@ -631,7 +638,11 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool 
can_flush)
else
oplock = 0;
 
+   if (IS_SHARELOCK(inode))
+   share_access = cifs_get_share_flags(cfile-f_flags);
+
if (tcon-unix_ext  cap_unix(tcon-ses) 
+   (share_access == FILE_SHARE_ALL) 
(CIFS_UNIX_POSIX_PATH_OPS_CAP 
le64_to_cpu(tcon-fsUnixInfo.Capability))) {
/*
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 039d9a1..7aed606 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1167,7 +1167,8 @@ 

[PATCH v7 5/7] NFSv4: Add O_DENY* open flags support

[Pavel Shilovsky]

by passing these flags to NFSv4 open request. Make it return
-ESHAREDENIED on share conflicts with other opens and disable
O_DENYDELETE support since NFSv4 doesn't support it.

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 fs/nfs/dir.c   |  4 
 fs/nfs/internal.h  |  3 ++-
 fs/nfs/nfs4file.c  |  4 
 fs/nfs/nfs4proc.c  |  4 +++-
 fs/nfs/nfs4super.c |  9 ++---
 fs/nfs/nfs4xdr.c   | 21 +
 fs/nfs/super.c |  6 +-
 7 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index f23f455..fe3215c 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1395,6 +1395,10 @@ int nfs_atomic_open(struct inode *dir, struct dentry 
*dentry,
dfprintk(VFS, NFS: atomic_open(%s/%ld), %s\n,
dir-i_sb-s_id, dir-i_ino, dentry-d_name.name);
 
+   /* No support for O_DENYDELETE */
+   if (open_flags  O_DENYDELETE)
+   return -EINVAL;
+
/* NFS only supports OPEN on regular files */
if ((open_flags  O_DIRECTORY)) {
if (!d_unhashed(dentry)) {
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 541c9eb..70cd1b0 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -6,7 +6,8 @@
 #include linux/mount.h
 #include linux/security.h
 
-#define NFS_MS_MASK (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_SYNCHRONOUS)
+#define NFS_MS_MASK (MS_RDONLY | MS_NOSUID | MS_NODEV | MS_NOEXEC | \
+MS_SYNCHRONOUS | MS_SHARELOCK)
 
 struct nfs_string;
 
diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index 13e6bb3..f5ec400 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -34,6 +34,10 @@ nfs4_file_open(struct inode *inode, struct file *filp)
dentry-d_parent-d_name.name,
dentry-d_name.name);
 
+   /* No support for O_DENYDELETE */
+   if (openflags  O_DENYDELETE)
+   return -EINVAL;
+
if ((openflags  O_ACCMODE) == 3)
openflags--;
 
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 261e9b9..6eabd2a 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -102,7 +102,7 @@ static int nfs4_map_errors(int err)
case -NFS4ERR_BADNAME:
return -EINVAL;
case -NFS4ERR_SHARE_DENIED:
-   return -EACCES;
+   return -ESHAREDENIED;
case -NFS4ERR_MINOR_VERS_MISMATCH:
return -EPROTONOSUPPORT;
case -NFS4ERR_ACCESS:
@@ -795,6 +795,8 @@ static struct nfs4_opendata *nfs4_opendata_alloc(struct 
dentry *dentry,
atomic_inc(sp-so_count);
p-o_arg.fh = NFS_FH(dir);
p-o_arg.open_flags = flags;
+   if (!IS_SHARELOCK(dir))
+   p-o_arg.open_flags = ~(O_DENYREAD | O_DENYWRITE);
p-o_arg.fmode = fmode  (FMODE_READ|FMODE_WRITE);
/* don't put an ACCESS op in OPEN compound if O_EXCL, because ACCESS
 * will return permission denied for all bits until close */
diff --git a/fs/nfs/nfs4super.c b/fs/nfs/nfs4super.c
index 569b166..a25a929 100644
--- a/fs/nfs/nfs4super.c
+++ b/fs/nfs/nfs4super.c
@@ -28,7 +28,8 @@ static struct file_system_type nfs4_remote_fs_type = {
.name   = nfs4,
.mount  = nfs4_remote_mount,
.kill_sb= nfs_kill_super,
-   .fs_flags   = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA,
+   .fs_flags   = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA |
+ FS_DOES_SHARELOCK,
 };
 
 static struct file_system_type nfs4_remote_referral_fs_type = {
@@ -36,7 +37,8 @@ static struct file_system_type nfs4_remote_referral_fs_type = 
{
.name   = nfs4,
.mount  = nfs4_remote_referral_mount,
.kill_sb= nfs_kill_super,
-   .fs_flags   = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA,
+   .fs_flags   = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA |
+ FS_DOES_SHARELOCK,
 };
 
 struct file_system_type nfs4_referral_fs_type = {
@@ -44,7 +46,8 @@ struct file_system_type nfs4_referral_fs_type = {
.name   = nfs4,
.mount  = nfs4_referral_mount,
.kill_sb= nfs_kill_super,
-   .fs_flags   = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA,
+   .fs_flags   = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA |
+ FS_DOES_SHARELOCK,
 };
 
 static const struct super_operations nfs4_sops = {
diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index e3edda5..cb0e8de 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -1325,7 +1325,8 @@ static void encode_lookup(struct xdr_stream *xdr, const 
struct qstr *name, struc
encode_string(xdr, name-len, name-name);
 }
 
-static void encode_share_access(struct xdr_stream *xdr, fmode_t fmode)
+static void encode_share_access(struct xdr_stream *xdr, fmode_t fmode,
+   int open_flags)
 {
__be32 *p;
 
@@ -1343,7 +1344,19 @@ static void encode_share_access(struct xdr_stream *xdr, 

[PATCH v7 6/7] NFSD: Pass share reservations flags to VFS

[Pavel Shilovsky]

that maps them into O_DENY* flags and make them visible for
applications on mounts with sharelock option.

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 fs/locks.c  |  1 +
 fs/nfsd/nfs4state.c | 46 +-
 fs/nfsd/nfsproc.c   |  1 +
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/fs/locks.c b/fs/locks.c
index 09c1d0e..60f3ce8 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -899,6 +899,7 @@ sharelock_lock_file(struct file *filp)
locks_free_lock(lock);
return error;
 }
+EXPORT_SYMBOL(sharelock_lock_file);
 
 static int __posix_lock_file(struct inode *inode, struct file_lock *request, 
struct file_lock *conflock)
 {
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index f9a5e62..b19cb3a 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -457,6 +457,19 @@ test_deny(u32 access, struct nfs4_ol_stateid *stp)
return test_bit(access, stp-st_deny_bmap);
 }
 
+static int nfs4_deny_to_odeny(u32 access)
+{
+   switch (access  NFS4_SHARE_DENY_BOTH) {
+   case NFS4_SHARE_DENY_READ:
+   return O_DENYREAD;
+   case NFS4_SHARE_DENY_WRITE:
+   return O_DENYWRITE;
+   case NFS4_SHARE_DENY_BOTH:
+   return O_DENYREAD | O_DENYWRITE;
+   }
+   return 0;
+}
+
 static int nfs4_access_to_omode(u32 access)
 {
switch (access  NFS4_SHARE_ACCESS_BOTH) {
@@ -2780,6 +2793,21 @@ nfsd4_truncate(struct svc_rqst *rqstp, struct svc_fh *fh,
 }
 
 static __be32
+nfs4_vfs_set_deny(struct nfs4_file *fp, unsigned long share_access,
+ unsigned long deny_access)
+{
+   int oflag, rc;
+   __be32 status = nfs_ok;
+
+   oflag = nfs4_access_to_omode(share_access);
+   fp-fi_fds[oflag]-f_flags |= nfs4_deny_to_odeny(deny_access);
+   rc = sharelock_lock_file(fp-fi_fds[oflag]);
+   if (rc)
+   status = nfserrno(rc);
+   return status;
+}
+
+static __be32
 nfs4_upgrade_open(struct svc_rqst *rqstp, struct nfs4_file *fp, struct svc_fh 
*cur_fh, struct nfs4_ol_stateid *stp, struct nfsd4_open *open)
 {
u32 op_share_access = open-op_share_access;
@@ -2800,6 +2828,14 @@ nfs4_upgrade_open(struct svc_rqst *rqstp, struct 
nfs4_file *fp, struct svc_fh *c
}
return status;
}
+   status = nfs4_vfs_set_deny(fp, op_share_access, open-op_share_deny);
+   if (status) {
+   if (new_access) {
+   int oflag = nfs4_access_to_omode(op_share_access);
+   nfs4_file_put_access(fp, oflag);
+   }
+   return status;
+   }
/* remember the open */
set_access(op_share_access, stp);
set_deny(open-op_share_deny, stp);
@@ -3033,7 +3069,7 @@ nfsd4_process_open2(struct svc_rqst *rqstp, struct svc_fh 
*current_fh, struct nf
 
/*
 * OPEN the file, or upgrade an existing OPEN.
-* If truncate fails, the OPEN fails.
+* If truncate or set_deny fails, the OPEN fails.
 */
if (stp) {
/* Stateid was found, this is an OPEN upgrade */
@@ -3047,6 +3083,10 @@ nfsd4_process_open2(struct svc_rqst *rqstp, struct 
svc_fh *current_fh, struct nf
status = nfsd4_truncate(rqstp, current_fh, open);
if (status)
goto out;
+   status = nfs4_vfs_set_deny(fp, open-op_share_access,
+  open-op_share_deny);
+   if (status)
+   goto out;
stp = open-op_stp;
open-op_stp = NULL;
init_open_stateid(stp, fp, open);
@@ -3745,6 +3785,10 @@ nfsd4_open_downgrade(struct svc_rqst *rqstp,
}
nfs4_stateid_downgrade(stp, od-od_share_access);
 
+   status = nfs4_vfs_set_deny(stp-st_file, od-od_share_access,
+  od-od_share_deny);
+   if (status)
+   goto out;
reset_union_bmap_deny(od-od_share_deny, stp);
 
update_stateid(stp-st_stid.sc_stateid);
diff --git a/fs/nfsd/nfsproc.c b/fs/nfsd/nfsproc.c
index 54c6b3d..ff95544 100644
--- a/fs/nfsd/nfsproc.c
+++ b/fs/nfsd/nfsproc.c
@@ -743,6 +743,7 @@ nfserrno (int errno)
{ nfserr_notsupp, -EOPNOTSUPP },
{ nfserr_toosmall, -ETOOSMALL },
{ nfserr_serverfault, -ESERVERFAULT },
+   { nfserr_share_denied, -ESHAREDENIED },
};
int i;
 
-- 
1.8.1.5

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 18:13+0200 Peter Rosin wrote:


On 2013-06-29 18:33, Alan W. Irwin wrote:

Those have been mentioned before here, and I have looked at them.
Cygwin is a very large collection of software so the number of bugs
that are reported does not seem excessive to me, and for my personal
needs (building and testing software on the Cygwin platform) I will
only be using a subset of Cygwin so I may avoid encountering
some of these bugs. Furthermore, some of these bugs (e.g.,
problems resizing a GUI) are not showstoppers, and most of them are
quite old. At the same time the latest Wine is far superior to
Wine-1.4 so some of those bugs may have just disappeared.  I hope to
find out about the actual status of Cygwin on Wine
bugs once I can get setup.exe to work on Wine.


I would like to point out that it seems that the current bug does not
appear to be *in* setup.exe, but rather occurs when setup.exe runs
a bash post-install script, where the bash.exe that interprets the
script depends on cygwin1.dll. If my analysis is correct, the bug
would occur also when duplicating the actions of setup.exe manually.
You would have to also duplicate the actions of all post-install
scripts, which is certainly more work and more error-prone than
duplicating the download and unpacking of a few tarballs.


Hi Peter:

That analysis is absolutely correct, and the current hang I am getting
for that post-install script
(/etc/postinstall/000-cygwin-post-install.sh) is a puzzler since that
occurs with or without the fork-fixed cygwin1.dll and the hang is new
behaviour compared to the result I got a month ago (obviously without
the fork-fixed cygwin1.dll) where I got an abort with an explicit
error message in agreement with the 24018 bug report. So I hope others
here with some cygwin experience will investigate further since I
might be doing something inadvertently different than before when I
replicated the behaviour reported in the 24018 bug report exactly.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

[PATCH v7 7/7] locks: Disable LOCK_MAND support for MS_SHARELOCK mounts

[Pavel Shilovsky]

Signed-off-by: Pavel Shilovsky pias...@etersoft.ru
---
 fs/locks.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/fs/locks.c b/fs/locks.c
index 60f3ce8..86f3a93 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1758,6 +1758,12 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, 
cmd)
goto out;
}
 
+   /* Disable LOCK_MAND support for FS mounted with MS_SHARELOCK */
+   if ((cmd  LOCK_MAND)  IS_SHARELOCK(f.file-f_path.dentry-d_inode)) {
+   error = -EPERM;
+   goto out;
+   }
+
can_sleep = !(cmd  LOCK_NB);
cmd = ~LOCK_NB;
unlock = (cmd == LOCK_UN);
-- 
1.8.1.5

Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Peter Rosin]

On 2013-06-28 23:37, Hin-Tak Leung wrote:
 --- On Fri, 28/6/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
 
 ... However, because of the Cygwin fork
 bug, Cygwin on
 Wine has largely been untested for the last three years so
 this could
 be a good opportunity to do such testing for the combination
 of Cygwin
 (with the fork fix) and recent Wine in case some Wine
 regression is
 discovered by such testing.
 
 what You really don't get it. setup.exe is simply *not* a necessity 
 for putting a cygwin installation under wine. There are many other ways of 
 installing cygwin into wine without running cygwin's installer. The easiest 
 is simply to copy the entire installed directory, plus importing a few 
 registry entries, from a genuine windows box which has cygwin on.
 
 (There are many people who bundles bits of cygwin with their software for 
 windows, for years; so if you are a full-time windows user, you might even 
 gain some bits of cygwin without knowing it, and without ever having seen the 
 official cygwin installer or even heard of it) . The problem is that even if 
 you manage to put it on, many part of cygwin don't work correctly under wine.
 
 Please don't confuse issues with running the official installer, and issues 
 with running the cygwin system (or part of) itself. You have been told *many 
 times*, in that thread, that setup.exe itself does not depend on cygwin, and 
 use no part of it.

Running the official installer invokes child processes that do indeed
require a functioning Cygwin DLL. I.e. post-install scripts (and pre-
remove scripts, but we're talking about the initial install so that's
out of scope).

The registry entries you speak about are a thing of the past, if you
are referring to mount points.

Cheers,
Peter

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Hin-Tak Leung]

--- On Mon, 1/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
... I hope your negative
 attitude
 toward the Cygwin toolchain is not typical of such
 developers.  After
 all, even though the Windows GNU toolchain code bases have
 diverged
 between the two groups of developers, there is still a
 common interest
 between MinGW and Cygwin developers regarding getting the
 GNU
 toolchain to work properly on Windows.
...

Look. You have been advised a few times, that it is possible and even easy to 
bypass installation-related problems and been given brief instructions on how 
to do so; you have also been told, *many times*, and *by the cygwin 
developers*, that you are just encounter one problems out of many, and there 
are more problems to come, in the thread you posted to the cygwin mailing list.

Going personal and accusing others of being biased is not a way of getting 
help. If you have bothered to look it up as you claim to do, while I have a 
formal association with mingw, I have made absolutely no contribution to mingw 
at all, ever; whereas I have made some patches available, etc to cygwin's GNU 
findutils (merged into coreutils eventually), LaTeX, emacs/xemacs, over a 
decade ago. My history with cygwin is about twice as old as my association with 
mingw. That's a matter of public record.

If you bother to look further, the main reason is really that cygwin is a 
commercial entity - part of Redhat now, but was a privately-own company until 
13 years ago when Redhat acquired part of it. Formal membership to cygwin has 
always been different from how formal membership to mingw operates, for that 
very reason; and that I live locally to where that company was, (and the part 
of cygwin that Redhat choose not to buy, still is), and probably know or have 
met some of the cygwin developers in person. I don't have the fortune to 
meet/know many, but they have my respects.

The cygwin people would have told you the exact same thing: running mingw on 
wine is fair easier and more straight-forward, and there are very simple 
technical reasons why that is the case; and that cygwin is not mingw, and there 
are important difference where wine is concerned. You seem to assume the 
difference between cygwin and mingw is small - they are not, and really a world 
apart, as far as wine is concerned.

Going via exaggeration/sensationalist (showstoppers) or personal attack is 
not going to win you any help. FWIW, on the latter point, few are interested in 
reading a 20-line introduction about your life (or lack of it) every time at 
the bottom of your posts. That's another thing that put people off from helping 
you.

Re: Fix to support input of characters with diacritic symbols using AltGr

[Ken Thomases]

On Jul 1, 2013, at 3:29 PM, Юрий Воротилов wrote:

 Fix to support input of characters with diacritic symbols using AltGr (e.g. 
 Latvian - AltGr+a=ā).
 Tested on Ubuntu 12.04 and Centos 6.
 I also have a bug opened in Crossover tracker:
 http://www.codeweavers.com/support/tickets/browse/?ticket_id=935141
 
 ---
  dlls/winex11.drv/keyboard.c |   45 
 +--
  include/winuser.h   |1 +
  server/queue.c  |5 -
  3 files changed, 31 insertions(+), 20 deletions(-)
 0001-Support-input-of-characters-with-diacritic-symbols-usi.txt

I don't believe this is the correct approach.  You don't want to be modifying 
the server and you can't arbitrarily add a new KEYEVENTF_* value.  You can't 
assume that applications won't leave junk in the non-standard bits of the flags 
when they call SendInput() or keybd_event().

This needs to be implemented entirely within the X11 driver.  It needs to 
properly translate your X11 keyboard layout into Win32 behavior.  If the 
problem is that AltGr is mapping to VK_MENU, and thus causing key events to 
generate WM_SYSKEYDOWN/UP and not go through translation, then you need to make 
AltGr not map to VK_MENU.  Although you really need to test that on Windows.  
My understanding is that AltGr appears to Windows apps as Alt+Control.

In any case, I know that, on Mac OS X, the Option key is used similarly to 
AltGr.  It accesses additional characters from the keyboard layout.  This works 
when Option is configured in the X keymap to generate XK_Mode_switch.  It 
requires no changes to Wine.  So perhaps the right approach is to make 
XK_ISO_Level3_Shift and XK_ISO_Group_Shift behave the same way as 
XK_Mode_switch.  (You could also just change your X keymap to actually map the 
key to XK_Mode_switch.)

-Ken

Re: Fix to support input of characters with diacritic symbols using AltGr

[Ken Thomases]

On Jul 1, 2013, at 4:26 PM, Ken Thomases wrote:

 On Jul 1, 2013, at 3:29 PM, Юрий Воротилов wrote:
 
 Fix to support input of characters with diacritic symbols using AltGr (e.g. 
 Latvian - AltGr+a=ā).
 Tested on Ubuntu 12.04 and Centos 6.
 I also have a bug opened in Crossover tracker:
 http://www.codeweavers.com/support/tickets/browse/?ticket_id=935141
 
 ---
 dlls/winex11.drv/keyboard.c |   45 
 +--
 include/winuser.h   |1 +
 server/queue.c  |5 -
 3 files changed, 31 insertions(+), 20 deletions(-)
 0001-Support-input-of-characters-with-diacritic-symbols-usi.txt
 
 I don't believe this is the correct approach.  You don't want to be modifying 
 the server and you can't arbitrarily add a new KEYEVENTF_* value.  You can't 
 assume that applications won't leave junk in the non-standard bits of the 
 flags when they call SendInput() or keybd_event().
 
 This needs to be implemented entirely within the X11 driver.  It needs to 
 properly translate your X11 keyboard layout into Win32 behavior.  If the 
 problem is that AltGr is mapping to VK_MENU, and thus causing key events to 
 generate WM_SYSKEYDOWN/UP and not go through translation, then you need to 
 make AltGr not map to VK_MENU.  Although you really need to test that on 
 Windows.  My understanding is that AltGr appears to Windows apps as 
 Alt+Control.
 
 In any case, I know that, on Mac OS X, the Option key is used similarly to 
 AltGr.  It accesses additional characters from the keyboard layout.  This 
 works when Option is configured in the X keymap to generate XK_Mode_switch.  
 It requires no changes to Wine.  So perhaps the right approach is to make 
 XK_ISO_Level3_Shift and XK_ISO_Group_Shift behave the same way as 
 XK_Mode_switch.  (You could also just change your X keymap to actually map 
 the key to XK_Mode_switch.)

Oh, and I forgot to mention: please don't rename variables unnecessarily 
(AltGrMask - KeyEventModifiers), make whitespace changes on lines you're not 
otherwise modifying (stuff in X11DRV_InitKeyboard()), or change trace formats 
arbitrarily (%x - %X).

-Ken

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[David Laight]

On Mon, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote:
 
 I would like to point out that it seems that the current bug does not
 appear to be *in* setup.exe, but rather occurs when setup.exe runs
 a bash post-install script, where the bash.exe that interprets the
 script depends on cygwin1.dll. If my analysis is correct, the bug
 would occur also when duplicating the actions of setup.exe manually.

If you read into what cygwin does when trying to emulate fork() it
is surprising it works at all!

Putting some effort into getting the shell (be it bash or an ash derivative)
and gmake to use posix_spawn() instead of fork() and adding posix_spawn()
to cygwin (for which patches are avaiable) would speed up cygwin no end
and probably avoid  some of these bugs (and the random fork failed errors).

One day I'll get annoyed at some issues with cygwin and start fixing them!
(Like getting ^C to work for windows console programs in mintty windows.)

David

-- 
David Laight: da...@l8s.co.uk

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Alan W. Irwin]

On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:


--- On Mon, 1/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
... I hope your negative

attitude
toward the Cygwin toolchain is not typical of such
developers.  After
all, even though the Windows GNU toolchain code bases have
diverged
between the two groups of developers, there is still a
common interest
between MinGW and Cygwin developers regarding getting the
GNU
toolchain to work properly on Windows.

...




Look. You have been advised a few times, that it is possible and

even easy to bypass installation-related problems and been given brief
instructions on how to do so.

The problem discussed on this thread is not with the generic part of
the installation you have referred to but instead the problem is with
running one of the post install scripts that is invoked by setup.exe.


you have also been told, *many times*,

and *by the cygwin developers*, that you are just encounter one
problems out of many, and there are more problems to come, in the
thread you posted to the cygwin mailing list.

Many times by you and once by a Cygwin developer.  I have answered both,
but I am going to try again now since you brought it up again.

Even if that assertion were true (something we don't know until some
Wine developer with an interest in Cygwin systematically looks at it
for the latest Wine to see how many Cygwin bugs are left for that much
improved version of Wine) it only strengthens my argument. The fact
remains, Cygwin is open-source software so in theory (i.e., the Wine
developer pursuing this opportunity will need some knowledge of
Cygwin) you know exactly what is going on with the calls to Windows
software, and you can also directly compare results for those calls
between the Wine version and Microsoft version of Windows. Therefore I
think it is obvious that Cygwin represents a good opportunity to get
rid of Wine bugs.  If there are a lot of such bugs like you and the
Cygwin developer assert, then it represents even a bigger opportunity
to debug those Wine issues with exact source code in hand that
demonstrates the issue.  I think we don't really know what
bugs are still left in recent Wine until a systematic evaluation is
done of Cygwin on Wine, but my argument stands whether
there are a lot of such bugs or only a few.


Going personal and accusing others of being biased is not a way of

getting help.  If you have bothered to look it up as you claim to do,
while I have a formal association with mingw, I have made absolutely
no contribution to mingw at all, ever.

Sourceforge lists you as a MinGW developer, but I believe you when you
state that is only a formal association.  I knew of that possibility
of just a formal association so that is why I was careful to put in
phrasing like apparently, and if this is true. I am sorry you
missed that phrasing and took that as a personal attack.

Regardless of your association or not with MinGW, I am still concerned
the opinions you have expressed here on the Cygwin tool chain are
biased. That is because I have my own bias. In short, I have a
prejudice against anyone stating anecdotal evidence concerning issues
with _any_ open-source software if they don't back up that anecdotal
evidence with a solid bug report.  For example, you stated some
anecdotal evidence about a bug in Cygwin cat, but when I requested a
reference for your associated bug report to Cygwin you were silent.
That told me a lot.


The cygwin people would have told you the exact same thing: running

mingw on wine is fair easier and more straight-forward.

That is obvious and strengthens the argument for using Cygwin
as a debugging tool for Wine.


[...]and that cygwin is

not mingw, and there are important difference where wine is concerned.
You seem to assume the difference between cygwin and mingw is small -
they are not, and really a world apart, as far as wine is concerned.

You are completely wrong about what I assume. Try reading what I have
said earlier today.  The two projects are obviously quite different
which is why I have stated earlier today that Cygwin represents a
different opportunity (and a more extensive opportunity because it is
a lot bigger) than MinGW/MSYS to debug Wine.  Of course, that
opportunity is there only if Cygwin _on Microsoft Windows_ mostly
works and is not riddled with bugs.  I think that is a fair assumption
since Cygwin does have a significant userbase that actually uses it on
Microsoft Windows.

Something about this opportunity to use a comparison of Cygwin's
behaviour on Microsoft Windows versus the Wine version to debug Wine
obviously bothers you, and because of that you have clearly stated you
would prefer the Wine developers here ignore this opportunity and work
on something else.  However, I completely disagree with your opinion
about that opportunity.  Any fixes to Wine that make it more like
Microsoft Windows will help _all_ Windows software being run on Wine.
That said, the actual Wine developers here 

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

[Austin English]

On Mon, Jul 1, 2013 at 7:11 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
 On 2013-07-01 19:58+0100 Hin-Tak Leung wrote:

 --- On Mon, 1/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
 ... I hope your negative

 attitude
 toward the Cygwin toolchain is not typical of such
 developers.  After
 all, even though the Windows GNU toolchain code bases have
 diverged
 between the two groups of developers, there is still a
 common interest
 between MinGW and Cygwin developers regarding getting the
 GNU
 toolchain to work properly on Windows.

 ...


 Look. You have been advised a few times, that it is possible and

 even easy to bypass installation-related problems and been given brief
 instructions on how to do so.

 The problem discussed on this thread is not with the generic part of
 the installation you have referred to but instead the problem is with
 running one of the post install scripts that is invoked by setup.exe.


 you have also been told, *many times*,

 and *by the cygwin developers*, that you are just encounter one
 problems out of many, and there are more problems to come, in the
 thread you posted to the cygwin mailing list.

 Many times by you and once by a Cygwin developer.  I have answered both,
 but I am going to try again now since you brought it up again.

 Even if that assertion were true (something we don't know until some
 Wine developer with an interest in Cygwin systematically looks at it
 for the latest Wine to see how many Cygwin bugs are left for that much
 improved version of Wine) it only strengthens my argument. The fact
 remains, Cygwin is open-source software so in theory (i.e., the Wine
 developer pursuing this opportunity will need some knowledge of
 Cygwin) you know exactly what is going on with the calls to Windows
 software, and you can also directly compare results for those calls
 between the Wine version and Microsoft version of Windows. Therefore I
 think it is obvious that Cygwin represents a good opportunity to get
 rid of Wine bugs.  If there are a lot of such bugs like you and the
 Cygwin developer assert, then it represents even a bigger opportunity
 to debug those Wine issues with exact source code in hand that
 demonstrates the issue.  I think we don't really know what
 bugs are still left in recent Wine until a systematic evaluation is
 done of Cygwin on Wine, but my argument stands whether
 there are a lot of such bugs or only a few.

While it's likely that debugging this (and other) Cygwin problems with
Wine would find and eliminate bugs from Wine, it also takes a lot of
effort and know how to do so. That time is often better spent on
issues that require less effort to debug, and help more user visible
applications.

In other words, while fixing Cygwin issues is a valuable effort, it
takes a lot of time and effort that is better spent elsewhere. If you
want to spend that time and effort, feel free to do so. But asking
others to spend their time to debug issues that fix Cygwin isn't
likely to find many volunteers.

--
-Austin

How not to ask for help Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine

[Hin-Tak Leung]

--- On Tue, 2/7/13, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:

  Going personal and accusing others of being biased is
 not a way of
 getting help. 

...In short, I have
 a
 prejudice against anyone stating anecdotal evidence
 concerning issues
 with _any_ open-source software if they don't back up that
 anecdotal
 evidence with a solid bug report.  For example, you
 stated some
 anecdotal evidence about a bug in Cygwin cat, but when I
 requested a
 reference for your associated bug report to Cygwin you were
 silent.
 That told me a lot.
...

That tells you only one thing: I don't care about Cygwin enough now to bother 
filing one more bug among those already filed. My time is more valuable than 
that. 13 years ago I used it daily and I made my own contributions, and that 
was then. Half of the time I file bugs on various projects because I have 
patches to attach/send, and this is not the case with cygwin now, and will not 
be. I don't intend to file a bug because I don't intend spend time fixing it. 
You wish.

I am not the one asking for help - you are. Launching personal attacks on 
people trying to help you is just not the way to do it. Nor is exaggeration, 
nor is 20-line of [lack of] life included in every e-mail.

If you want help, ask for it, nicely, and keep it short.