From: "Alex Xu (Hello71)" Subject: Re: [PATCH v3 0/5] Implement reflink support Message-Id: <1631204702.ry8kt7531y.none@localhost> Date: Thu, 09 Sep 2021 12:36:36 -0400 In-Reply-To: <3FC301D9-63EA-479E-BE30-FB1C7DC59CD6@gmail.com> References: <20210823155653.228592-1-alex_y_xu.ref@yahoo.ca> <20210823155653.228592-1-alex_y_xu@yahoo.ca> <3FC301D9-63EA-479E-BE30-FB1C7DC59CD6@gmail.com> Excerpts from Stefan Dösinger's message of August 24, 2021 7:24 am: > > >> Am 23.08.2021 um 18:56 schrieb Alex Xu (Hello71) : >> >> If hard links or symlinks were >> used, if an application such as winetricks writes to a system file, it >> would overwrite the central copy. With reflink, the file blocks will be >> transparently copied by the Linux kernel so that each Wine prefix can be >> independent. > > What happens if the Wine installation files themselves are updated, e.g. because the package manager installs a newer Wine? With enough wine changes a wine prefix update will be triggered; Do your setupapi changes update the reflinked files to new reflinked files? > > A presumably preexisting problem that is already handled: What happens if I run Wine out of my build tree. It creates a new prefix with a copy of PE d3d9.dll. I change the d3d9 code and recompile d3d9.dll in my build tree and run Wine. What will the result be? (I say preexisting because even without reflink somehow Wine uses my newly updated file. But do applications that look at C:\windows\system32\d3d9.dll see the new contents too?) > > Reflink is intended to have identical semantics to ordinary file copy. Once the copy is complete, neither updating the source nor destination file affects the other one. wineboot triggers update based on wine.inf mtime. When this happens, it checks if the destination is still a fakedll, then copies the new dll. Since reflink has same semantics as copy, updating the source file afterwards will not affect the destination file. For the copy, wineboot uses the same functions as the initial populate, so it will work the same way, using reflink if supported by the filesystem or regular copy if not. The same applies when running out of build tree. However, in this case, wine loader has an internal special case to load built-in dlls from build tree instead of SystemRoot/PATH. This is, again, unaffected by reflink. Once the files in the build tree are updated, the wine prefix will become out of date and require updating to pick up the new files.