bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47058: 28.0.50; Dired Z: insert-directory: Reading directory: No suc


From: Eli Zaretskii
Subject: bug#47058: 28.0.50; Dired Z: insert-directory: Reading directory: No such file or directory, CrossLine_linux_x86
Date: Wed, 22 Sep 2021 10:54:07 +0300

> Date: Wed, 22 Sep 2021 07:15:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: mvar.40k@gmail.com, larsi@gnus.org, mcenturion@fing.edu.uy, 
>     arthur.miller@live.com, 47058@debbugs.gnu.org
> 
> > If you move a directory over another by renaming, the previous directory 
> > is gone, and replaced by the one you moved in its place, right?  I'm not 
> > talking about what GNU mv does, I'm talking about what Emacs will do 
> > when renaming a directory into another one.
> 
> Sorry, I don't understand your question.  With the patch, if the output 
> directory already exists, an "File already exists" is displayed, as I 
> think should be the case.

Should it?

The use case that I have in mind is this:

  . directory DIR exists on disk, and has files in it
  . the archive includes directory DIR with files in it, not
    necessarily identical to those on disk: some files on disk don't
    exist in the archive, and vice versa

When I unpack such an archive outside Emacs, what happens (and what
I'd expect to happen) is the following:

  . files in DIR on disk that don't exist in the archive are unaltered
  . files in DIR in the archive that don't exist on disk are unpacked
    into DIR on disk
  . non-directory files in DIR that exist both on disk and in the
    archive are overwritten with the version in the archive
  . sub-directories in DIR that exist both on disk and in the archive
    are NOT being overwritten; instead, they are recursively handled
    as described above, i.e. missing files are added and common files
    are overwritten
  . as a corollary from the last item, an empty sub-directory of DIR
    in the archive that also exists on disk will NOT be emptied on
    disk, but will be left intact with the files it had before
    unpacking

Will the unpacking you propose behave in the same way?  If not, we
need to augment it so it does.

In particular, unpacking into an existing directory should "just
work", it makes little sense to me to fail in that case, as that isn't
what Tar and similar utilities do, at least IME.  We may decide asking
the user for confirmation in that case, but given the confirmation
should proceed as above.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]