Re: EOL conversion of files in .tar archives

[Kenichi Handa <handa@m17n.org>]

In article <u1wh9kswd.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> I'd like to suggest an alternative change that is local to
> tar-mode.el, see below.  It mimics what arc-mode.el does.

It seems that the alternative change works well too
especially because arc-mode is doing the same thing.  But...

> +(defun tar-file-name-handler (op &rest args)
> +  "Helper function for `tar-extract'."
> +  (or (eq op 'file-exists-p)
> +      (let ((file-name-handler-alist nil))
> +	(apply op args))))

Is it ok to check only file-exists-p?  How about
file-readable-p?

> Sorry, that patch was incomplete, and so did an imperfect job.  Please
> use the one below.

Does this new version have the following problem too?

> This solves the problem with the EOL decoding, but reveals a very
> strange phenomenon: dos-w32.el and dos-w32.elc behave differently.
> The latter is preloaded into Emacs on Windows, and if I visit a file
> inside a tarball (after applying the patch below), plain text files
> with Unix EOLs get latin-1-unix buffer-file-coding-system, instead of
> the expected undecided-unix.  But if I manually load dos-w32.el and
> visit the same file again, its buffer-file-coding-system is now
> undecided-unix, as expected!  Is this some problem with the byte
> compiler?

---
Kenichi Handa
handa@m17n.org