Wine Reflink Support Continues To Be Worked On For Significant Space Savings

[shmerl]

Can anyone explain why the prefix can't simply symlink libraries to Wine installation by default?

[Snaipersky]

Can anyone explain why the prefix can't simply symlink libraries to Wine installation by default?

Symlinks would work, until a file needs to be modified. Then it gets modified everywhere. Reflinks would work the same way, except changed blocks would be local to a single prefix.

[shmerl]

Symlinks would work, until a file needs to be modified. Then it gets modified everywhere. Reflinks would work the same way, except changed blocks would be local to a single prefix.

OK, that makes sense, thanks.

[Chugworth]

Well it's about time for the Linux desktop distros to standardize around Btrfs and put Ext4 out to the pasture. How many years does it take to declare that a filesystem is stable? Drive snapshots should be an expected feature in any modern desktop OS.

[NobodyXu]

If ext4 doesn't have support, how much use is this actually going to bring? Afaik, damn near everyone (debian/ubuntu most notably) is still on ext4 unless you're a fedora/arch user and like to live dangerously (btrfs).

You can also use XFS instead.
It’s stable enough and provides good performance.

[oiaohm]

Symlinks would work, until a file needs to be modified. Then it gets modified everywhere. Reflinks would work the same way, except changed blocks would be local to a single prefix.

Not quite right.

OK, that makes sense, thanks.

If people obey rules and never run wine as root symlink could be ok to a point due to the fact the file synlinked for installed wine for to a normal user would not be able to modify. Of course this brings you to application would have a failure to overwrite that it can respond badly to. Some anti cheats in some games will be banning a users game account because they were not able to open a file for writing(please note open for writing not in fact write anything). Welcome to the fun of anti-cheat software for you lot open core system files in read/write just to checksum them by reading them.

Of course if user has built wine in their home directory and running wine from their home directory synlinked fails as Snaipersky said due to no privilege split.

Now if user runs as root as you are not meant to-do with wine due to security risk yes the symlink is going to screw up everywhere again.

reflink is really less of a pain in the but.

[leipero]

Symlinks would work, until a file needs to be modified. Then it gets modified everywhere. Reflinks would work the same way, except changed blocks would be local to a single prefix.

So they are overcomplicating it for no reason at all as I see it. You have shared dll's folder, all symlinks point towards that, if dll's are different (by override, hash, whatever), store it locally = problem solved, it always reads local prefix anyway, so why bother, symli9nk would simply mimic the actual file, file would replace it if needed.
In that way, you save space, and if required for different version of the file, add to the prefix, so prefix could grow, but usually it wouldn't, and even if it grows, it would be only for those overrides.
There's probably something I'm missing here, but, that looks like the best solution without overcomplication.

[pal666]

damn near everyone (debian/ubuntu most notably) is still on ext4

why should anyone care about your problems? i have btrfs

[pal666]

We already discussed that in previous news about reflink, but I still don't understand why you can't use symlinks for that.

because symlinks are not normal files. windows supports symlinks, so now all your dlls will look like symlinks on windows. no doubt it will break something

[pal666]

So they are overcomplicating it for no reason at all as I see it. You have shared dll's folder, all symlinks point towards that, if dll's are different (by override, hash, whatever), store it locally = problem solved, it always reads local prefix anyway, so why bother, symli9nk would simply mimic the actual file, file would replace it if needed.
In that way, you save space, and if required for different version of the file, add to the prefix, so prefix could grow, but usually it wouldn't, and even if it grows, it would be only for those overrides.
There's probably something I'm missing here, but, that looks like the best solution without overcomplication.

yes, you are missing something here. you suggested overcomplicated algorithm under disguise of simplification while reflink solution is trivial "use reflink instead of copy if available"