From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Michalis V." Newsgroups: gmane.emacs.bugs Subject: bug#47058: 28.0.50; Dired Z: insert-directory: Reading directory: No such file or directory, CrossLine_linux_x86 Date: Tue, 21 Sep 2021 12:18:50 +0300 Message-ID: <87a6k6qoat.fsf@cnu407c2zx.nsn-intra.net> References: <86o8fqdab2.fsf@protected.rcdrun.com> <8735qpz4dh.fsf@fing.edu.uy> <875yuuq4lh.fsf@gmail.com> <87k0jaft05.fsf@gnus.org> <83wnnaz67v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13004"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: mvar.40k@gmail.com, Lars Ingebrigtsen , mcenturion@fing.edu.uy, arthur.miller@live.com, 47058@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 21 11:19:19 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mSbvq-0003AB-OX for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Sep 2021 11:19:18 +0200 Original-Received: from localhost ([::1]:54688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mSbvp-0005wr-Hs for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Sep 2021 05:19:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mSbva-0005wj-QA for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 05:19:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33347) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mSbva-0008JE-IX for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 05:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mSbva-0001zF-El for bug-gnu-emacs@gnu.org; Tue, 21 Sep 2021 05:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Michalis V." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Sep 2021 09:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47058 X-GNU-PR-Package: emacs Original-Received: via spool by 47058-submit@debbugs.gnu.org id=B47058.16322159407629 (code B ref 47058); Tue, 21 Sep 2021 09:19:02 +0000 Original-Received: (at 47058) by debbugs.gnu.org; 21 Sep 2021 09:19:00 +0000 Original-Received: from localhost ([127.0.0.1]:44893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSbvY-0001yz-1d for submit@debbugs.gnu.org; Tue, 21 Sep 2021 05:19:00 -0400 Original-Received: from mail-ed1-f47.google.com ([209.85.208.47]:38780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mSbvW-0001yk-Ak for 47058@debbugs.gnu.org; Tue, 21 Sep 2021 05:18:58 -0400 Original-Received: by mail-ed1-f47.google.com with SMTP id dj4so16031146edb.5 for <47058@debbugs.gnu.org>; Tue, 21 Sep 2021 02:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=1gWRRB/K/3I8cBDkxNywlPkiFrRlKZAu60KDftTegyY=; b=WmMYoStEOJ41RMaUjbGb+N3d8wXQuLp16F3RNvdR6RRbGz4TDCICpMvbchY0gfX47m DluFi4Hl3CUYMb5NfspLFmX2FlW1JwJPuEUXELUuWogEXJzzvfgWSHTbzT/leA4QKShK hNsz6k4a0A3hi7REJqkRL2iy7QHTaRlPSF104MKkZDXLWDvA8g4QbmTofJuhscCWzmei PwBSiC46SIiageblfADOBJJHUJVfbALJM9xNnaDRTfqV4G0CXw48yxdfyiMUoMPFf3iF hO+K3GDIGKddrsG0KWxsoBTdUhcv38ugN3WwWBg1EiiASkgELpcfO4hrFPxz9cwnrXSr a2Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=1gWRRB/K/3I8cBDkxNywlPkiFrRlKZAu60KDftTegyY=; b=z62PcJC6B+vO/DRQbw/GsRXbs1uGKZnZiFIQZ/lGDQ0bySwjFT/KIVVJJTLvJKFc98 rxLkS1DLk6a4vANH8CqzwRC6S3wQQGMx5dkL8WNqsDHYa2HMVw9fMcNYcHv+gEYcbddv yu9VypIZqbidRhvGPE/bxVdbj3hVU5EmPOTouMyYZ+V3CLvUT/cb8Cl6b20ZQi0s+RPw dKtVH/dkMbiNu3je/CVtKngDHdawDJ7W7xbLLssiPb+uaTO7f6B+4mrF/vfYDfp5QZS3 QNfWPkRZ8zJSs4DzNuT591+HmG1ihsXHQ4yF1FyBmq7/pfMPYS+LJvI2QpsNhsZB6+X5 25jg== X-Gm-Message-State: AOAM533EuZ5ffAfUNcgF2q0b5qJ4xX8KIFdu7TC8isI7hu3rJ+5sQxZ0 cioNva1tMQ04DVklt5SpEWk= X-Google-Smtp-Source: ABdhPJwZGVfv3j3DRX0yzu/sobxI+VCCe8rSN2frCFdkRtpPi09ekJfCzbk+ZgGy6vlsoVGL8iXuGg== X-Received: by 2002:a05:6402:21c6:: with SMTP id bi6mr25093400edb.372.1632215932447; Tue, 21 Sep 2021 02:18:52 -0700 (PDT) Original-Received: from cnu407c2zx.nsn-intra.net ([2a02:2149:8842:bf00:fe15:b4ff:fee9:4f35]) by smtp.gmail.com with ESMTPSA id d7sm703010eds.42.2021.09.21.02.18.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Sep 2021 02:18:52 -0700 (PDT) X-Google-Original-From: "Michalis V." In-Reply-To: <83wnnaz67v.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 21 Sep 2021 11:24:36 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214933 Archived-At: Eli Zaretskii writes: > So I think the correct solution for this bug is to catch the error of > the missing directory, and instead present the user with an > informative message saying that the files were extracted into a > directory such-and-such. Because otherwise 'Z' in the OP's use case > did TRT: it unpacks the file into the current directory, as instructed > by the archive, the only problem is the error it signals. That > archives should not generally have file names without leading > directories is not our problem; using 'tar' or some other unpacking > command would produce the same result, and there's no reason Emacs > should work differently. In fact, one could argue that Emacs should > work the same, to be consistent with those other methods of unpacking. > > I don't think we should have this "solution" in Emacs 28. hi Eli, thanks for the feedback. I agree that changing the behavior of the command just to solve this corner case is not ideal. Actually i'm neither for nor against merging this patch. It was more of an example solution to trigger some feedback (and i got a first glimpse of ert :) Btw one of the reasons i went with this approach and included -C parameter for tars were some security concerns expressed in #25611. There's also a suggestion in the discussion there that Z should just decompress and not untar the archive and the un-tarring should be a separate action/procedure. That would be a drastic solution to this problem but on the other hand it would make sense semantically (extract != decompress). What is your opinion on this? in any case i'll try to assemble another patch based on your suggestion. thank you, Michalis