Files wiped after find and replace (OS: Fedora 36)

[TimTaylor]

System details

RStudio Edition : Desktop
RStudio Version : 2022.02.3 Build 492
OS Version      : Fedora 36
R Version       : 4.1.3

Describe the problem in detail

Ran find and replace with:

Find = cli::cli_abort
Replace = cli_abort

Saw variations of the following message in the find and replace window for each file where replacements occured and found that the files had been wiped (still there but all content deleted and 0 bytes size)

system error 18 (Invalid cross-device link) [path: /tmp/RtmpQzqwYj/replaceb491092aecc.txt, target-path /home/[REDACTED] OCCURRED AT rstudio::core::Error rstudio::core::CilePath::copy(const rstudio::core::FilePath&, bool) const src/cpp/shared_core/FilePath.cpp:812

Describe the behavior you expected

Find and replace works and doesn't delete my files

• I have read the guide for submitting good bug reports.
• I have installed the latest version of RStudio, and confirmed that the issue still persists.
• If I am reporting an RStudio crash, I have included a diagnostics report.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

[TimTaylor]

Will try and get something more reproducible to share later today.

[Enchufa2]

Could you please share details about your file systems? The output from df -h would be useful.

[TimTaylor]

❯ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           3.1G  2.0M  3.1G   1% /run
/dev/nvme0n1p3  930G   63G  865G   7% /
tmpfs           7.8G  8.0K  7.8G   1% /tmp
/dev/nvme0n1p3  930G   63G  865G   7% /home
/dev/nvme0n1p2  974M  262M  645M  29% /boot
/dev/nvme0n1p1  599M   14M  585M   3% /boot/efi
tmpfs           1.6G 1004K  1.6G   1% /run/user/1000

❯ mount | column -t
proc            on  /proc                      type  proc             (rw,nosuid,nodev,noexec,relatime)
sysfs           on  /sys                       type  sysfs            (rw,nosuid,nodev,noexec,relatime,seclabel)
devtmpfs        on  /dev                       type  devtmpfs         (rw,nosuid,seclabel,size=4096k,nr_inodes=1048576,mode=755,inode64)
securityfs      on  /sys/kernel/security       type  securityfs       (rw,nosuid,nodev,noexec,relatime)
tmpfs           on  /dev/shm                   type  tmpfs            (rw,nosuid,nodev,seclabel,inode64)
devpts          on  /dev/pts                   type  devpts           (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs           on  /run                       type  tmpfs            (rw,nosuid,nodev,seclabel,size=3244688k,nr_inodes=819200,mode=755,inode64)
cgroup2         on  /sys/fs/cgroup             type  cgroup2          (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot)
pstore          on  /sys/fs/pstore             type  pstore           (rw,nosuid,nodev,noexec,relatime,seclabel)
efivarfs        on  /sys/firmware/efi/efivars  type  efivarfs         (rw,nosuid,nodev,noexec,relatime)
bpf             on  /sys/fs/bpf                type  bpf              (rw,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p3  on  /                          type  btrfs            (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=257,subvol=/root)
selinuxfs       on  /sys/fs/selinux            type  selinuxfs        (rw,nosuid,noexec,relatime)
systemd-1       on  /proc/sys/fs/binfmt_misc   type  autofs           (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=18230)
mqueue          on  /dev/mqueue                type  mqueue           (rw,nosuid,nodev,noexec,relatime,seclabel)
hugetlbfs       on  /dev/hugepages             type  hugetlbfs        (rw,relatime,seclabel,pagesize=2M)
debugfs         on  /sys/kernel/debug          type  debugfs          (rw,nosuid,nodev,noexec,relatime,seclabel)
tracefs         on  /sys/kernel/tracing        type  tracefs          (rw,nosuid,nodev,noexec,relatime,seclabel)
fusectl         on  /sys/fs/fuse/connections   type  fusectl          (rw,nosuid,nodev,noexec,relatime)
configfs        on  /sys/kernel/config         type  configfs         (rw,nosuid,nodev,noexec,relatime)
tmpfs           on  /tmp                       type  tmpfs            (rw,nosuid,nodev,seclabel,size=8111720k,nr_inodes=1048576,inode64)
/dev/nvme0n1p3  on  /home                      type  btrfs            (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/home)
/dev/nvme0n1p2  on  /boot                      type  ext4             (rw,relatime,seclabel)
/dev/nvme0n1p1  on  /boot/efi                  type  vfat             (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,errors=remount-ro)
sunrpc          on  /var/lib/nfs/rpc_pipefs    type  rpc_pipefs       (rw,relatime)
tmpfs           on  /run/user/1000             type  tmpfs            (rw,nosuid,nodev,relatime,seclabel,size=1622340k,nr_inodes=405585,mode=700,uid=1000,gid=1000,inode64)
gvfsd-fuse      on  /run/user/1000/gvfs        type  fuse.gvfsd-fuse  (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal          on  /run/user/1000/doc         type  fuse.portal      (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

[Enchufa2]

Ok, so when you say "find and replace", you mean Edit > Find in Files... (also Ctrl+Shift+F), then hit "Replace" in the "Find in Files" panel, then "Replace with:" something, then "Replace All", right? I can reproduce this following those steps (I did it in a new project with fake files to avoid data loss). I see the same error message and the file(s) is truncated.

[TimTaylor]

Yes - apologies that is what I meant.

[Enchufa2]

It's strange because the error seems like a rename that went sideways, but the copy functionality is implemented via boost::filesystem::copy_file, which shouldn't have that problem? Not sure, I don't know the implementation details. For reference, we have Boost 1.76 in F36.

[TimTaylor]

Out of my depth here but just checked my update history to see if anything jumped out. Yesterday this was updated:

kf5-filesystem-5.96.0-1.fc36.x86_64           Tue 12 Jul 2022 07:39:35 BST

Could this be related?

[Enchufa2]

Did you use this same functionality before without any trouble?

[TimTaylor]

yes - but not sure if I have since I updated rstudio which was

rstudio-desktop-2022.02.3+492-1.fc36.x86_64   Wed 15 Jun 2022 09:09:03 BST

I'd be surprised if I hadn't used it in the last month which points to an update in Fedora surfacing the issue but can't be sure.

[Enchufa2]

I tried:

• 2022.02.2 Build 485 in a machine that still has F34 -> cannot reproduce.
• 2022.02.1 Build 461, a downgrade in my current machine with F36 -> still reproducible.

I did an upgrade 3 days ago for this second machine. Not sure if this was working before because I never used this functionality.

[Enchufa2]

Interestingly enough, it works fine with kernel 5.18.6 but fails (with the error reported here) with 5.18.10, the latest one available in F36. I assume you are running the latter.

[TimTaylor]

yep - 5.18.10-200

[TimTaylor]

Running a toolbox with f37 (not yet released), rstudio 2022.07.0+548 and kernel 5.18.10 works without issue for me.

[Enchufa2]

That's... weird! And if you downgrade RStudio there?

[TimTaylor]

Assuming I'm doing this correctly then it worked ..... As it was a new toolbox I had to download the old versions directly from koji

rstudio-desktop-2022.02.3+492-2.fc37.x86_64.rpm
rstudio-2022.02.3+492-2.fc37.x86_64.rpm

I installed both of these with sudo dnf in xxxxxxx --allowerasing and then everything seemed to work. Does this point to it being an issue with F36?

[Enchufa2]

Here's a standalone minimal reprex:

#include <iostream>
#include <fstream>
#include <boost/filesystem.hpp>

int main() {
    std::string test = "test.txt", temp = "/tmp/test.txt";
    std::ofstream testf(test), tempf(temp);
    testf << "asdf" << std::endl;
    tempf << "fdsa" << std::endl;
    testf.close();
    tempf.close();

    try {
        boost::filesystem::copy_option option =
            boost::filesystem::copy_option::overwrite_if_exists;
        boost::filesystem::copy_file(temp, test, option);
        std::cout << "worked ok" << std::endl;
    } catch(const std::exception& e) {
        std::cout << "Error: " << e.what() << std::endl;
    }
    remove(test.c_str());
    remove(temp.c_str());
    return 0;
}

then

$ g++ test.cpp -o test -lboost_filesystem && ./test # should output "worked ok"
Error: boost::filesystem::copy_file: Invalid cross-device link: "/tmp/test.txt", "test.txt"

[TimTaylor]

And I can confirm the above works in rawhide (with Boost 1.78). @Enchufa2 - Assume I should close this here? As this seems to work with Boost 1.78 is there much I can do apart from run Rstudio in a rawhide toolbox. I'm assuming that boost 1.78 wont find it's way in to f36?

[Enchufa2]

It seems clear to me that the bug is in Boost < 1.78 (probably < 1.77 judging from the filesystem fixes listed for v1.77) with running kernel >= 5.18.10 (or some patch between 5.18.6 and this one).

So given that RStudio 2022.02.x supports Boost 1.69, let's keep this open for the RStudio people to take a look, because this bug will bite for any distro with a new enough kernel. @kevinushey If another release in the 2022.02.x series is not in your radar, maybe you could suggest a patch to apply directly into our F36 builds?

@TimTaylor The workaround for now is to either start the system with an older kernel, which is not great, or to run the newest RStudio version for F37 in a toolbox, which is compiled against Boost 1.78.

[Enchufa2]

Reported here too.

[jwakely]

This is a Boost 1.76.0 bug: boostorg/filesystem#184

It completely failed to handle the EXDEV error from copy_file_range, so can't copy files between different filesystems.

We can patch the Fedora Boost package, but other distros and users with self-built Boost 1.76.0 will have the same problem still.

[Enchufa2]

Thanks, @jwakely for the quick assessment. That fix is included in v1.77. If we can backport that patch in F35 and F36, it would be great. We don't know how many applications may be relying on boost::filesystem::copy_file, and given how common is to copy files from /tmp and the fact that this is mounted as tmpfs in most hosts, I'd say there are high chances of file corruption happening out there.

[kevinushey]

I think the official builds of RStudio are already using Boost 1.78, which has the associated fix for this issue? In other words, I don't think there's anything to be done on the RStudio side; the issue here is specifically for Fedora 35 and 36 (which need backports of the associated Boost fix). Is that correct?

[Enchufa2]

Only the latest version. Version 2022.02.3 bundles Boost 1.69, so it is affected by this bug.

[jwakely]

Are you sure? I think the change to use copy_file_range was new in Boost 1.74.0, see boostorg/filesystem@9182b4c

[jwakely]

the issue here is specifically for Fedora 35 and 36 (which need backports of the associated Boost fix)

Updated boost packages for F35 and F36 are queued for the updates-testing repos now.

[Enchufa2]

Are you sure? I think the change to use copy_file_range was new in Boost 1.74.0, see boostorg/filesystem@9182b4c

No, I'm not sure, I assumed that this was a problem for <= 1.76. But if this is the case, then we can close this.

Updated boost packages for F35 and F36 are queued for the updates-testing repos now.

Thanks!

[mikebessuille]

Just double-checking... seems this issue has been resolved on fedora's side, and I can close this now?

[Enchufa2]

Correct.