)]}'
{
  "commit": "44ed3556bad809797f7b06a4a88918fd8a23d6fe",
  "tree": "c4e9fb126d25d2f08e972365a480e40612502850",
  "parents": [
    "24e93025ee434a58d35e5abb283c5bcc9a13e477"
  ],
  "author": {
    "name": "NeilBrown",
    "email": "neilb@suse.de",
    "time": "Thu Dec 03 15:58:56 2009 -0500"
  },
  "committer": {
    "name": "Trond Myklebust",
    "email": "Trond.Myklebust@netapp.com",
    "time": "Thu Dec 03 21:26:36 2009 -0500"
  },
  "message": "NFS4ERR_FILE_OPEN handling in Linux/NFS\n\nNFS4ERR_FILE_OPEN is return by the server when an operation cannot be\nperformed because the file is currently open and local (to the server)\nsemantics prohibit the operation while the file is open.\nA typical case is a RENAME operation on an MS-Windows platform, which\nprevents rename while the file is open.\n\nWhile it is possible that such a condition is transitory, it is also\nvery possible that the file will be held open for an extended period\nof time thus preventing the operation.\n\nThe current behaviour of Linux/NFS is to retry the operation\nindefinitely.  This is not appropriate - we do not expect a rename to\ntake an arbitrary amount of time to complete.\n\nRather, and error should be returned.  The most obvious error code\nwould be EBUSY, which is a legal at least for \u0027rename\u0027 and \u0027unlink\u0027,\nand accurately captures the reason for the error.\n\nThis patch allows a few retries until about 2 seconds have elapsed,\nthen returns EBUSY.\n\nSigned-off-by: NeilBrown \u003cneilb@suse.de\u003e\nSigned-off-by: Trond Myklebust \u003cTrond.Myklebust@netapp.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "741a562177fc3f587dcd1e1019f3cfe53c367de8",
      "old_mode": 33188,
      "old_path": "fs/nfs/nfs4proc.c",
      "new_id": "40da0d5bc5fc1677911ca4061fca99f10cc9555f",
      "new_mode": 33188,
      "new_path": "fs/nfs/nfs4proc.c"
    }
  ]
}