From unknown Fri Jun 20 07:19:16 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#58781 <58781@debbugs.gnu.org> To: bug#58781 <58781@debbugs.gnu.org> Subject: Status: 28.2; move-file-to-trash may move file across filesystems Reply-To: bug#58781 <58781@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:19:16 +0000 retitle 58781 28.2; move-file-to-trash may move file across filesystems reassign 58781 emacs submitter 58781 Gustavo Barros severity 58781 normal tag 58781 security thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 25 16:00:58 2022 Received: (at submit) by debbugs.gnu.org; 25 Oct 2022 20:00:58 +0000 Received: from localhost ([127.0.0.1]:52464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onQ6c-0004zC-7e for submit@debbugs.gnu.org; Tue, 25 Oct 2022 16:00:58 -0400 Received: from lists.gnu.org ([209.51.188.17]:44696) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onQ6a-0004z5-8K for submit@debbugs.gnu.org; Tue, 25 Oct 2022 16:00:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onQ6Z-0001PH-SZ for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2022 16:00:55 -0400 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1onQ6Y-0000gd-7u for bug-gnu-emacs@gnu.org; Tue, 25 Oct 2022 16:00:55 -0400 Received: by mail-pg1-x534.google.com with SMTP id g129so10941232pgc.7 for ; Tue, 25 Oct 2022 13:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ZRVZ/i7RBwu6mrlCP0oMaiiQGSlasFpCAVhKdL+/6/g=; b=m+8xOefeGgwOtBG/4JGhMp/SHd2wgkGbAzbvwBPxraTSN73pfSESZ1bwpE6OHKxdnH pg9+7nzzcD4ffronyWUpTbZs0nZg8R0n73EMMV/UgmO1dOyBc7oDAFU2C0uwEoftOcfG vy4mqEPeQixpHsZUw/cJNUhyFWMAkVEQ4NOjhELb/pM4AlNIKiLOyo7ZTEqOr+YK9/dG vwB38aNKSlUPqD9Wvd7Ryv2nitMW5oETDXZJoZRjE08rqnw3y8vRbBg2V80W80lcvfYn Z9mmbOSSI+0HNyX6c1NGWo+BCwur6LTEWtwRTDy98rpZnF3BYkL6sEaxjqO+Zc0TZOib 02cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZRVZ/i7RBwu6mrlCP0oMaiiQGSlasFpCAVhKdL+/6/g=; b=msvZroeclSrXWQCHYUTkO5r382lio/RkbyBQis+WdfIcmWQD8BaoBa2mC7jsAGRF5g llgLi4CMyRve65aN2lfzLZN0/AVQ/Oym06FoOwknFYnobAIwH6Iqr/4jpYZnCCjr67ry aXZy30laBqWADz1nf33FGH1UTNmYAruWpTyR+EmX3bDaleIIWbHMRjRA9NrTu/tiIkyo T+s8HdxnVI8wcgPRmKt9qmY5BNf+rJ8IK2rFTSR0+90DnF0DcwXy4fVzhisxmOlzXLF/ XHFDFtkze8xOApn7GQ45U0pmxi+u2HRsYedIt3ROGrTmve16jj+C5fTE0fm7YLJliLWD CN5Q== X-Gm-Message-State: ACrzQf0N/mKv+bAIFTX3W48JNky8iMOvenVG8s5MatQyfGxsKY2ZVCl+ pJnTeaKRbO95vc3q4qP1lYZICDA7ju0bIRWHNLZfW/0wK3c9bQ== X-Google-Smtp-Source: AMsMyM5DY4fyF/ybWou2UiYP50Outur9a3J1jb093wuS37EF1gbHTV7FeE83rYN/wkLLJwQFNwM60Yw1TbeDKotms6o= X-Received: by 2002:a05:6a00:3249:b0:565:fc2c:ad79 with SMTP id bn9-20020a056a00324900b00565fc2cad79mr40081380pfb.72.1666728049135; Tue, 25 Oct 2022 13:00:49 -0700 (PDT) MIME-Version: 1.0 From: Gustavo Barros Date: Tue, 25 Oct 2022 17:00:37 -0300 Message-ID: Subject: 28.2; move-file-to-trash may move file across filesystems To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::534; envelope-from=gtvbrs@gmail.com; helo=mail-pg1-x534.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Hi All, I'm trying to investigate bug#58721 (https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01987.html), couldn't figure it out yet, but in the process of doing so, I've found another issue. Namely, that `move-file-to-trash' may move the file across filesystems with some undesired implications, including potential security risk. This happens because, for the case using the freedesktop.org method, in setting trash directory, the procedure is the following: (xdg-data-dir (directory-file-name (expand-file-name "Trash" (or (getenv "XDG_DATA_HOME") "~/.local/share")))) There's no provision to check whether `xdg-data-dir' belongs to the same filesystem (partition) as the file being moved there. As a result, the `move-file-to-trash' may move the file across filesystems. Indeed, I've tested it and, if you are trashing a file from a different partition, it ends in "~/.local/share" regardless. This is a problem for at least two reasons. First, what should be a cheap operation, a simple "rename", can become very costly if what is being trashed is large, because now the file has to be physically moved. Second, it may be a security risk. It certainly is for my setup, for example. It involves two partitions, one for the operating system, unencrypted, which includes "/home/username/", and another one, luks encrypted, where I keep my user files, and which is symlinked to "/home/username/". So, trashing a file from dired, with such a setup, results in the files being stored unencrypted, when they shouldn't. I wouldn't say there's nothing much peculiar in this setup, it is certainly legitimate. I'm not sure what's the standard expected behavior (I suppose the freedesktop.org specs for it). But my distro's file manager (which happens to be `nemo' from Linux Mint) certainly does not do that. It sends such files to a different trash directory at the root of the other partition's mount point. Best regards, Gustavo. From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 25 17:58:07 2022 Received: (at 58781) by debbugs.gnu.org; 25 Oct 2022 21:58:07 +0000 Received: from localhost ([127.0.0.1]:52539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onRvz-0007sZ-0j for submit@debbugs.gnu.org; Tue, 25 Oct 2022 17:58:07 -0400 Received: from mail-pg1-f169.google.com ([209.85.215.169]:38905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onRvw-0007s3-FX for 58781@debbugs.gnu.org; Tue, 25 Oct 2022 17:58:05 -0400 Received: by mail-pg1-f169.google.com with SMTP id 20so12894363pgc.5 for <58781@debbugs.gnu.org>; Tue, 25 Oct 2022 14:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uHEgkH9D7aQpDO1uQoh3nn1hXJT7XX2ftK+1Xs9RYbg=; b=G8E2PvfRr8E5mmm2/SS6c0yj9nK1oPeQRLa0YwKLsAvCzWlz3Fbb8GNyEDIud0Wum7 f++xx98vgxPZf1XTISMQVgrOHIYspcJO/Z0d43OkdQs6taNyaL/oiE1f14DXDDXmN2by 2PikJVDNuhhXx/1B2Eij9ov8giBpTahaXzBoNiSK02gN4qmdjfWRoBjQwFR3d+ksjjFY PArsgAC+HJ47Gs/msG/gzlvAC1lL4ostKn87tGLD2UJ3Yncr36iu8OnYFHjvDhOVam5Y /wmgMqclDq3LNVTDx2Rn6/OPacY8vMIJc50/oyRo5rlbMyjygYGv5+hxMNM037f5Wn6S s/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uHEgkH9D7aQpDO1uQoh3nn1hXJT7XX2ftK+1Xs9RYbg=; b=LFUfYZXW1VYCD941L1do4LDGs7GyUIrbl0/WIayFfkORppnXfXPgaC/2fxRE6vtWc2 L948nhUNN8eL6J4QJMGdepLyPPjDcSF2B45JQlwfW/HsZJS3s7pNTOYUWpG4a4miIRR+ +EiCWj7OI1Dyxyi2EvAtNfLnS42p2oD+Uc4L8JQwgn2ev37rPvqaXQw9zEslEr5bcgFH FeaQW9t/c6yu4yiyzmRo3hYvjZ1CBYH3G64A+dMjkuq1tv6KBkhhIh57wjI/k5EKLz1w wc9i6+cq7EgYt8t5k1MT9BdbymwL0oilT+AY7IdiHp+OnmfI8f4bSF+qFuNVg0nl4R99 fQTQ== X-Gm-Message-State: ACrzQf2E0cNGjG6rnvPX5hS/Uciq4FdlcwzO9o9GlAOVLUooZoA61mbm 68taJx/3PAflQqTdk/VUR6x5GbM/s8bnazXjLhxZPmEV4R4= X-Google-Smtp-Source: AMsMyM7jkZ+ByDJIoqZ90TXbVMvyl/Pmwz6k+RK6SCLNGhxqlYnZzrJ19Skxpw51lya/q09e5pPy7Wh5Z3cBwLIuUSU= X-Received: by 2002:a63:84c2:0:b0:46e:f239:354c with SMTP id k185-20020a6384c2000000b0046ef239354cmr14316332pgd.147.1666735078105; Tue, 25 Oct 2022 14:57:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gustavo Barros Date: Tue, 25 Oct 2022 18:57:46 -0300 Message-ID: Subject: Re: 28.2; move-file-to-trash may move file across filesystems To: 58781@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 58781 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi All, a couple of additions to this report. First, I did some searching on the freedesktop.org specs, which I found at: https://specifications.freedesktop.org/trash-spec/trashspec-lates= t.html. The relevant bit seems to be: "A system can have one or more trash directories. The contents of any trash directory are to be compliant with the same standard, described below. For every user a =E2=80=9Chome trash=E2=80=9D directory MUST be available. = Its name and location are $XDG_DATA_HOME/Trash; $XDG_DATA_HOME is the base directory for user-specific data, as defined in the Desktop Base Directory Specification . The =E2=80=9Chome trash=E2=80=9D SHOULD function as the user's main trash d= irectory. Files that the user trashes from the same file system (device/partition) SHOULD be stored here (see the next section for the storage details). A =E2=80=9Chome trash=E2=80=9D directory SHOULD be automa= tically created for any new user. If this directory is needed for a trashing operation but does not exist, the implementation SHOULD automatically create it, without any warnings or delays. The implementation MAY also support trashing files from the rest of the system (including other partitions, shared network resources, and removable devices) into the =E2=80=9Chome trash=E2=80=9D directory . This i= s a =E2=80=9Cfailsafe=E2=80=9D method: trashing works for all file locations, t= he user can not fill up any space except the home directory, and as other users generally do not have access to it, no security issues arise. However, this solution leads to costly file copying (between partitions, over the network, from a removable device, etc.) A delay instead of a quick =E2=80=9Cdelete=E2=80=9D operation can be unpleasant to = users. An implementation MAY choose not to support trashing in some of these cases (notably on network resources and removable devices). This is what some well known operating systems do. It MAY also choose to provide trashing in the =E2=80=9Ctop directories=E2= =80=9D of some or all mounted resources." Etc. This means `move-file-to-trash' is technically within specs, since "The implementation MAY also support trashing files from the rest of the system (including other partitions, shared network resources, and removable devices) into the =E2=80=9Chome trash=E2=80=9D directory." I hear= tily disagree though with the "no security issues arise" statement. And I still think it would be better to support trashing to "top directories". Of course, this makes this report a "feature request" rather than a "bug". Second, for anyone else half as concerned with this as I am, you may be interested in a workaround too. For the time being, I'm using: (defun system-move-file-to-trash (filename) (if-let ((exec (executable-find "gio"))) (let ((fn (directory-file-name (expand-file-name filename)))) (set-process-sentinel (start-process "trash-file" nil exec "trash" fn) (lambda (_proc event) (when (string-match-p "^exited abnormally.*" event) (message "Sorry, couldn't trash the file."))))) (error "Executable `gio' not found, can't trash file."))) This is somewhat ad hoc, using the way `move-file-to-trash' is constructed to support Windows I suppose, but it gets things done. It is system dependent too, but it is a matter of finding the right command line incantation for trashing a file in your system to adjust things. Best regards, Gustavo. On Tue, 25 Oct 2022 at 17:00, Gustavo Barros wrote: > > Hi All, > > I'm trying to investigate bug#58721 > (https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01987.html), > couldn't figure it out yet, but in the process of doing so, I've found > another issue. Namely, that `move-file-to-trash' may move the file > across filesystems with some undesired implications, including > potential security risk. > > This happens because, for the case using the freedesktop.org method, > in setting trash directory, the procedure is the following: > > (xdg-data-dir > (directory-file-name > (expand-file-name "Trash" > (or (getenv "XDG_DATA_HOME") > "~/.local/share")))) > > There's no provision to check whether `xdg-data-dir' belongs to the > same filesystem (partition) as the file being moved there. As a > result, the `move-file-to-trash' may move the file across filesystems. > Indeed, I've tested it and, if you are trashing a file from a > different partition, it ends in "~/.local/share" regardless. > > This is a problem for at least two reasons. First, what should be a > cheap operation, a simple "rename", can become very costly if what is > being trashed is large, because now the file has to be physically > moved. Second, it may be a security risk. > > It certainly is for my setup, for example. It involves two > partitions, one for the operating system, unencrypted, which includes > "/home/username/", and another one, luks encrypted, where I keep my > user files, and which is symlinked to "/home/username/". So, trashing > a file from dired, with such a setup, results in the files being > stored unencrypted, when they shouldn't. I wouldn't say there's > nothing much peculiar in this setup, it is certainly legitimate. > > I'm not sure what's the standard expected behavior (I suppose the > freedesktop.org specs for it). But my distro's file manager (which > happens to be `nemo' from Linux Mint) certainly does not do that. It > sends such files to a different trash directory at the root of the > other partition's mount point. > > Best regards, > Gustavo. From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 26 02:22:59 2022 Received: (at 58781) by debbugs.gnu.org; 26 Oct 2022 06:22:59 +0000 Received: from localhost ([127.0.0.1]:53076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onZoZ-0008L5-DW for submit@debbugs.gnu.org; Wed, 26 Oct 2022 02:22:59 -0400 Received: from mail-oa1-f45.google.com ([209.85.160.45]:35773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onZoX-0008KY-8w for 58781@debbugs.gnu.org; Wed, 26 Oct 2022 02:22:57 -0400 Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-13b103a3e5dso18855831fac.2 for <58781@debbugs.gnu.org>; Tue, 25 Oct 2022 23:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:mime-version :references:in-reply-to:from:from:to:cc:subject:date:message-id :reply-to; bh=ZeWpy132U6icfHRVeo3FETvtII+GSOv+uhCjJYjMvf8=; b=GsogkgG8Jpa0damOc05qqncu29sViQfudIj7a2M5chx2RwBX7VU5Gb+kztwJhlhiIf wjexsv63Ia+NuoqvmY/7yGjY0UAoOpahD95bGmUnxQ2+5Hs3Wa4CPs/xcggPBuFWN8N9 Dri5KzQ5j4fdJRDauguhRRr7WEaYjhFEp+3BS/2ZquAU9Zm9GsLdHHcYbjhpnRR1ma9s 0FIxGRc9rWCtgKRl4EDSIavWYdwPNAwL6DduEDeBg4Bvm+br3aqh0kDLGWJXbCsWQHcv X+crxQWM4z4GyFbTU9tnZsCxSJ6VtwC93KmZV8bNEby0YtYdHwdVtCmUxsZ42mezrfTg 4pWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:mime-version :references:in-reply-to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=ZeWpy132U6icfHRVeo3FETvtII+GSOv+uhCjJYjMvf8=; b=pVwx4LLzmP/QJOaiwxEJ5peLbAKFJS69Ga5ngqGRePP9W93glm0iBVOhtmbpNg7t8S GD5fR3PYzlKb7UywNzwpLk8lJjZzPQ/++BzGQGSwp2WpKwWzVIxuuaJrZI/EKLF1P10e rmZqPRHNBBcV1r5n6jcWu6txib8h3UV2UvjL7xaKkCpqR966br1DaOxwGPeWzM1NcitS W2aEdNhVVynpLmbmyNO4CQ5XnHxtb138bs5jCWCIpv0Ifo8Kl++55XXACQezaIAxXAvX VuHPRgFDhNS0QYo17MmmS26HnLWoTk3YoE1VIH23T3YfZIxoJz50RUxckvolwRR9uK9m xO6A== X-Gm-Message-State: ACrzQf3r6FsckK4VnLbk9iCULGIcramBRCGagwO/b6EdgTFTirtsjPJl 6xO+mrpyAJ/611DC6YM8VnrRwhTNANWBH0TnkTU= X-Google-Smtp-Source: AMsMyM5U4iCmbdGVcRTAdpojAS0UND14AeGYA0ATGdh+LxyBh4s+XvTGXvA0pxu/GINtaGeGvMa3yD3U5UEY1lb+D3s= X-Received: by 2002:a05:6870:d79a:b0:136:50d7:faa9 with SMTP id bd26-20020a056870d79a00b0013650d7faa9mr1194643oab.92.1666765371660; Tue, 25 Oct 2022 23:22:51 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Oct 2022 23:22:51 -0700 From: Stefan Kangas In-Reply-To: References: X-Hashcash: 1:20:221026:58781@debbugs.gnu.org::ZrMpH4JS0uy4TkCx:5OId MIME-Version: 1.0 Date: Tue, 25 Oct 2022 23:22:51 -0700 Message-ID: Subject: Re: bug#58781: 28.2; move-file-to-trash may move file across filesystems To: Gustavo Barros , 58781@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58781 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 58781 + security thanks Gustavo Barros writes: > This means `move-file-to-trash' is technically within specs, since > "The implementation MAY also support trashing files from the rest of > the system (including other partitions, shared network resources, and > removable devices) into the =E2=80=9Chome trash=E2=80=9D directory." I he= artily > disagree though with the "no security issues arise" statement. Yes, that argument overlooks what happens when files are moved from encrypted partitions to unencrypted ones. That is bad. Maybe someone should bring this issue to the xdg mailing list? BTW, I also wonder why there is no "xdg-trash" script that we could use. > And I still think it would be better to support trashing to "top > directories". Of course, this makes this report a "feature request" > rather than a "bug". Agreed, but I don't think this makes it into a non-bug. > Second, for anyone else half as concerned with this as I am, you may > be interested in a workaround too. For the time being, I'm using: > > (defun system-move-file-to-trash (filename) > (if-let ((exec (executable-find "gio"))) > (let ((fn (directory-file-name (expand-file-name filename)))) > (set-process-sentinel > (start-process "trash-file" nil exec "trash" fn) > (lambda (_proc event) > (when (string-match-p "^exited abnormally.*" event) > (message "Sorry, couldn't trash the file."))))) > (error "Executable `gio' not found, can't trash file."))) > > This is somewhat ad hoc, using the way `move-file-to-trash' is > constructed to support Windows I suppose, but it gets things done. It > is system dependent too, but it is a matter of finding the right > command line incantation for trashing a file in your system to adjust > things. Could you write this up as a proper patch, instead? From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 26 07:06:03 2022 Received: (at 58781) by debbugs.gnu.org; 26 Oct 2022 11:06:03 +0000 Received: from localhost ([127.0.0.1]:53465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oneEV-00017N-DP for submit@debbugs.gnu.org; Wed, 26 Oct 2022 07:06:03 -0400 Received: from mail-pg1-f169.google.com ([209.85.215.169]:34505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oneET-00016t-8f for 58781@debbugs.gnu.org; Wed, 26 Oct 2022 07:06:01 -0400 Received: by mail-pg1-f169.google.com with SMTP id 128so14446958pga.1 for <58781@debbugs.gnu.org>; Wed, 26 Oct 2022 04:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wjU16vF5JYdbjHFZrQIQpOTqbFDKav6pmExrVeReGJ4=; b=QADCMZgEZzg9poAWvQHtELskPL00ZElsxeJ0yaICra463BnGtzcd/ut9mXYASJf8AU avxALz3Xf2GD/l/3NvRQpkfW28YT72mv2yVB9ugwIUXc68l4+d5dRLJMEVF1MGEkt+BT 5BWj0IEQhBnk3E1UVeOaWhtb1lTJEgyqmcCth54c63SVAUx0unBGp4mwRtlIheTllnIU F28vgxnrkKZccbdxU7RgbcgLtS5lHQMtUz0WIn3G+G0d9bNzMFZlRdlAHQvnvRx61IRE SmcttTBatLYF2+0mUrB4bmGESV7y7vTIOf3EtcbHxNhx/acCKFvVPDfPjl5lCYN18leG UskA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wjU16vF5JYdbjHFZrQIQpOTqbFDKav6pmExrVeReGJ4=; b=ccJKVB15tEhk7R+EXv5d+QniffsRmWH45gDjT2EYu0PvksT5XACARDu0TAlGJOn6Lm 79gP5sV/DOgofR3Oh2Z80lVx6aQ4ckLlINUT4rya4izfs+AvZTrBAzsnHASKalW8K8e6 ySVV75tQqNpk8OHuh/Ldwt4/DDc7llW9Ey4AmqRvoFEJGcq/2WN+1BIX9VCHiXjezowV sPAGvKHsbppycC36rz6LgVA9p3phjTTOcYzWTzssKL7DMBeg22Vh7puGworH/NQGoOc5 We53mt1WREnjToKAWboPxSlm2znD+2Kie3Cd5OLcDEGunFh7JKdrD8xU2YOEVcuWsSyd hXfA== X-Gm-Message-State: ACrzQf2B9VDoj0f629kN260ChWA/WprkiWiMI1EwZ5CjTRsm7u73SIav 45b6qOn/tjbwLIJeWeYoZIpoWL7wU2Qa/YNYn94= X-Google-Smtp-Source: AMsMyM40OPKs6SSw943r6FJHl49ZSZONz3xXja8UlGJNFvrTUSDCsilO8p82RZiyZ0JdyAe+9CDOPX9EdOkjFvvT3zk= X-Received: by 2002:a63:f924:0:b0:46b:1a7d:3b91 with SMTP id h36-20020a63f924000000b0046b1a7d3b91mr37529820pgi.133.1666782355343; Wed, 26 Oct 2022 04:05:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gustavo Barros Date: Wed, 26 Oct 2022 08:05:43 -0300 Message-ID: Subject: Re: bug#58781: 28.2; move-file-to-trash may move file across filesystems To: Stefan Kangas Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 58781 Cc: 58781@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi Stefan, On Wed, 26 Oct 2022 at 03:22, Stefan Kangas wrote: > Yes, that argument overlooks what happens when files are moved from > encrypted partitions to unencrypted ones. That is bad. > Agreed, but I don't think this makes it into a non-bug. Thanks for looking into this. And, particularly, for the way you classified the report. It is my understanding too that this should be cause for concern. > Could you write this up as a proper patch, instead? I don't think this snippet is a proper general solution to the problem, except as a temporary workaround for anyone interested to keep in their init files. I shared it in this spirit, at least. As far as I searched, "gio" stands for "Gnome Input/Output", I presume this is distro specific. Also, even if it was not, "gio trash" appears to have some limitations in that some places are not supported like "system internal mounts" (eg. "/tmp/", this is the reason for the sentinel there), so some further handling of cases would still be necessary. Besides, unfortunately I cannot sign a patch (no papers), so I have to contribute in other ways. I'm not that well acquainted with `files.el', but as far as I've looked into `move-file-to-trash', I think the right way to handle it would be directly there, or in a dedicated `xdg-trash', as you suggest. It is more complicated than the current standing but it appears not to be overly so. It's really three cases, and then there are the checks for "$topdir/.Trash". Anyway, I didn't seem to find any "universal Linux way" available for the operation so, as far as I can tell, relying on the system tools would not be a wise alternative. Best regards, Gustavo.