bug#61326: Adding --no-add-suffix to zip patch

[Ruijie Yu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Adam Sjøgren via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> writes:

> Ruijie writes:
>
>> Maybe, at least in the meantime, we change it such that all write
>> operations for zip create files in temp, and move to / overwrite the
>> original file when done? Although I don’t have a full understanding on
>> how that would be done and whether there are problems along with it.
>
> That sounds like a good solution, for archives with no '.' in the filename.
>
> I guess the main problem is if the archive is huge, updating an existing
> archive might (?) be more efficient than creating an entirely new one.
>
> Another way to go about it could be to temporarily rename the archive to
> have a name with a '.' in it, make the change, and then rename it back;
> conceptually:
>
>   mv a a.zip
>   # update a.zip rather than a
>   mv a.zip a
>
> That has its own set of possible problems.
>
> Maybe you could make a link to the original archive, where the link has
> a '.' in the name, have zip update the file via the link and then remove
> the link again; conceptually:
>
>   ln a a.zip
>   # update a.zip rather than a
>   rm a.zip
>
> I think I like this the most, but again...

I like the link solution, but I don't think we can reliably "link"
without knowing that we actually can do so -- i.e., on MS Windows, IIUC,
one needs admin privilege to create symlinks on cmd unless something in
the registry is changed.  Also, on old MS Windows versions like XP and
earier, I believe it is impossible to create symlinks at all. (Do we
still support them?)

Come to think of it, I think your mv idea might be better and even
easier to implement than my zip-offsite-then-overwrite idea.  I might
lean towards that method if people have no bias when I work on the patch
in a couple hours.

Best,


RY