X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:references :in-reply-to:content-type:content-id:content-transfer-encoding :mime-version; q=dns; s=default; b=gZK2aw2bdyYZw5hqtlP9W5B5MYsKd 1GXyGqFT4U3fcd5E9cDG7r/GplwAr9XAhOrgt09RyOPI1dwYnB2ZLP0sdinA4XJM lR2IcThAqSgXdUN34kwxrcW2G1ob7DSOpnNvu6SAm498gyO6f4oSCXcKGQxQaDuM 4xQwKUNOYiu3Fw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:references :in-reply-to:content-type:content-id:content-transfer-encoding :mime-version; s=default; bh=dX87xOInHTslawlnhUwff61md5w=; b=a8B nNbepegUD0EavNKX2NXh5LocTmAenywHpED7pwPWmq7+BGE7DZFVHvDYlkzTXTlC 91LuT3kD2/PUWOwNlrqJ+8J5KLOXZCrnuW2vkRYVLHHS9AaR8quA3C1vUuGozqiw YYiVJ5WiDU/zsjnu9q0YqBUrY+aeodWgiEuJ2uOU= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_00,CYGWIN_OWNER_BODY,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=yesterday, news X-HELO: na01-by2-obe.outbound.protection.outlook.com From: Bill Zissimopoulos To: "cygwin AT cygwin DOT com" Subject: Re: FUSE for Cygwin - was: Re: Fork and Windows Heap Date: Sat, 18 Jun 2016 20:03:49 +0000 Message-ID: References: <20160618080235 DOT GA3332 AT calimero DOT vinschen DOT de> In-Reply-To: <20160618080235.GA3332@calimero.vinschen.de> authentication-results: spf=none (sender IP is ) smtp.mailfrom=billziss AT navimatics DOT com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-office365-filtering-correlation-id: b16848b1-744a-442a-99b1-08d397b3aa9a x-microsoft-exchange-diagnostics: 1;CY1PR07MB2199;6:b167nCB4mle7+cCsi4roY5VbPwZy561c4yxQUPAgcbxIeSTr8rh24/XXhqj5bkAsw6v6nr0TbUKWFA/uo65PG6h5KKq5xH4cZgnAIcRrB6BL5g4GiPmo+ylaY+fqhHrz71JQnTosfUWGttTQ7mqJB+ALb/xLUBhffvS559NgTmzQtvb0XITWqe0qFFWK+4VSM25J/jZ0TxRMg+13o1vJGc831AHfxjsWk233t9DDN//16IOFB09u6hzPAE9t+GTA/L3dEcihgs00sp688SrrurB5Yqq6jtWyareYNgMp4D+zTiI00nyNfdnFKFzGsFmA;5:Fr/aefSXd61CGq6cHxB0ws0jXYPLUceDAot5oE26Uwn00Eka3Dnov00yb8Z7PdP9AyGIc/K9B0fvieg6Jtp75VIyWlOteyjr+W49185uhGxEnc+Vreu3nJKh1k4YKLeZhFYMru4DMEsp+4ENrkTdPA==;24:3VEmwtd3VERugyaDroRbQ3WN3zpYM5gmkpQMy/QTVZyX00et+7F5zp46rjy1/XCXToFWhh6A4iRkkQj6cIeXY+Dj7MzdYnJ7L5eFwvheddQ=;7:+agIDIgg3sE7lGU6VI36WTid5CIj05qhrk7lFQrx2+ehDoiBv22Xhm7Znj9X//dlYz1LgZRqNAT3AxqLKnClzprNMerYpQHg55sxqNuOhh92YZVZJGza+uJcmTCX0AqFmIK+qMKCel1qzwmzUKDPkwqvUw9R9qCgFZ6mUUlYIxUxcU4+wAmkwJhoiHvzCGjO0UqARywX4Yx0j1iwo/liFGp38DgIidfu7EvAqjA4Vq4xM6VYqmo7M8Vlz5GFSP0d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2199; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(63843785518722)(176295241369792); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041072)(6043046);SRVR:CY1PR07MB2199;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2199; x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(7916002)(3905003)(199003)(377454003)(189002)(24454002)(54356999)(76176999)(7846002)(8936002)(68736007)(5640700001)(86362001)(50986999)(101416001)(2501003)(2906002)(3660700001)(87936001)(3280700002)(122556002)(92566002)(5002640100001)(5004730100002)(77096005)(189998001)(110136002)(36756003)(15975445007)(2900100001)(11100500001)(2950100001)(450100001)(10400500002)(3846002)(107886002)(8676002)(81166006)(1730700003)(6116002)(586003)(102836003)(2351001)(81156014)(97736004)(106356001)(99286002)(105586002)(106116001)(19580395003)(19580405001)(66066001)(94096001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR07MB2199;H:CY1PR07MB2199.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: navimatics.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1403D5E5DEAF1144A7A6AB2868F09264 AT namprd07 DOT prod DOT outlook DOT com> MIME-Version: 1.0 X-OriginatorOrg: navimatics.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2016 20:03:49.9934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 21071be9-4f9a-413b-89ac-8353a5d2410a X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2199 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id u5IK4Hkv001826 On 6/18/16, 1:02 AM, "Corinna Vinschen" wrote: >>but I eventually had to change it for a number of issues (notably Rename >> support). > >For rename support you can use the index number as well, usually, >since you can open a file by index number. At least on NTFS. Unfortunately it is not as simple as that. A proper Rename implementation needs to conform to rules that effectively require the FSD to maintain filename/path information about open files. From "FILE_RENAME_INFORMATION structure” [1]: << Special rules for renaming open files: * A file cannot be renamed if it has any open handles, unless it is only open because of a batch opportunistic lock (oplock) and the batch oplock can be broken immediately. * A file cannot be renamed if a file with the same name exists and has open handles (except in the batch-oplock case described earlier). * A directory cannot be renamed if it or any of its subdirectories contains a file that has open handles (except in the batch-oplock case described earlier). >> In particular the third bullet point mandates that the FSD keeps information not only about files that are open, but also of their hierarchical relationships. The easiest way to do this on Windows is to maintain a mapping of file names to open files. >>I am not saying that it would not be possible to change this >> part of WinFsp, I just believe that it is a non-trivial change at this >> moment. > >Ok. I have thought more about this. As mentioned, originally the FSD maintained a mapping of IndexNumber to “FileNode” somewhat similar to UNIX. This is because it is important for an FSD to be able to identify when the same file is being reopened; for example, to properly implement file deletion (a file gets deleted only when its last handle is closed) or sharing or caching. When I had to implement Rename, bullet point (3) above complicated matters. So I ended up maintaining two tables for a while, one for IndexNumbers and one for file names. Then I ended up scrapping the IndexNumber table when I decided that I would not implement hard links (for a variety of reasons). Perhaps what I should have done instead is to maintain IndexNumber relationships (parent/child) and do my rename tests based on that. That’s what a VFS system would do, although I am not sure that it is the cleanest solution within a Windows FSD. Compounding this the user mode file system may not even send me back real IndexNumber’s, so then I would have to fake them (e.g. file name hash). In any case I am going to shelve this for a while and come back to it at a later time as there are lots of higher priority (for me) things to do on WinFsp. -- In other news I made a new release yesterday and I am happy to say that this release supports Cygwin. I am able to compile SSHFS with a minimal patch and it runs correctly under Cygwin. The SSHFS-Win repo is here [2]. I may actually go the extra mile and create a libfuse.dll so that things like FUSEPY can work out of the box. Bill [1] https://msdn.microsoft.com/en-us/library/windows/hardware/ff540344(v=vs.85) .aspx [2] https://bitbucket.org/billziss/sshfs-win