GNU bug report logs - #61326
30.0.50; Editing fil in zip file without extension save creates new file

Previous Next

Full log

View this message in rfc822 format

From: Ruijie Yu <ruijie <at> netyu.xyz>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: asjo <at> koldfront.dk, 61326 <at> debbugs.gnu.org
Subject: bug#61326: [DRAFT PATCH v2] Work around zip's filename extension limitation (was: Adding --no-add-suffix to zip patch)
Date: Fri, 10 Feb 2023 16:40:25 +0800

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Ruijie Yu <ruijie <at> netyu.xyz>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, asjo <at> koldfront.dk
>> Date: Thu, 09 Feb 2023 00:48:15 +0800
>>
>> Here is a preliminary patch that contains some "REVIEW" comments where I
>> need inputs.
>
> Thanks, but could you perhaps post diffs disregarding the whitespace
> changes?  That would make it easier to review the real changes.

Thanks, done.

>> -(defun archive-*-write-file-member (archive descr command)
>> +;; REVIEW: is there a better name than AVOID-EXTLESS-P?
>> +(defun archive-*-write-file-member (archive descr command
>> +                                            &optional avoid-extless-p)
>
> ensure-extension?

That sounds better, and I have renamed the variable in this iteration.

>> +    ;; REVIEW: the diff here is because the previous code had TAB's
>> +    ;; (while assuming each TAB is 4 spaces), and my Emacs replaced
>> +    ;; them with spaces.  What is the status quo on this kind of diff?
>> +    ;; I can remove them if we consider this change excessive and/or
>> +    ;; intrusive.
>
> TABs in Emacs are by default 8 columns, not 4.
>
> It is OK to convert TABs to spaces when changing the code in Lisp, but
> please do that only for the last commit, to make the review process
> easier.  For all the draft versions, please use "git diff" options
> that cause Git to ignore changes in whitespace.
>
> Thanks.

Thanks, I will keep that in mind.  I have also made some rearrangements
in the code to minimize delta.

In addition, I fixed an issue from the first iteration: in the first
iteration, the user would be prompted to revert buffer from disk if the
rename was in action; in this iteration this should no longer be the
case -- that is, the user should expect no difference between filenames
with extensions and without.

As pointed out in the commit message, two things remain: to ensure that
all write operations to extensionless zip archives behave correctly, and
to have some way to test that things continue to work in the future.

[0001-lisp-arc-mode.el-Work-around-zip-s-filename-limitati.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

Best,


RY

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.