From: Jon Turney <jon.turney@dronecode.org.uk>
To: cygwin-apps@cygwin.com
Subject: Re: setup and colons in filenames
Date: Thu, 26 Oct 2017 16:14:00 -0000 [thread overview]
Message-ID: <03e94ec4-db88-8997-40a0-1c63b1a010bd@dronecode.org.uk> (raw)
In-Reply-To: <f8a36b67-8050-77a1-50ce-f6c512a1f954@dronecode.org.uk>
On 25/10/2017 20:23, Jon Turney wrote:
> On 25/10/2017 16:50, Ken Brown wrote:
>> This is a followup to the thread started here:
>>
>> Â Â https://cygwin.com/ml/cygwin-patches/2017-q4/msg00012.html
>>
>> Currently setup's parse_filename is not correctly parsing filenames in
>> /etc/setup/installed.db that contain colons, as explained in the above
>> thread. It would be easy to fix this by just ripping out the 'base'
>> function, except for the fact that parse_filename is called by
>> ScanFindVisitor::visitFile.
>
> Since older setup cannot correctly parse an installed.db containing
> filenames like that, we should probably bump the installed.db version at
> the same time as fixing this.
>
>> I don't know enough about WIN32_FIND_DATA to know whether the call to
>> 'base' is needed for that use of parse_filename. If so, is it safe to
>> skip all colons in that setting, since we're dealing with Win32
>> filenames and they don't see the colons in Cygwin filenames?
>
> Yeah, that's about as far as I got before giving up...
>
>> Do we need two versions of parse_filename, one that calls base and one
>> that doesn't?
>
> This might be the easiest solution :)
It gets better: We only go down the whole route of using
ScanFindVisitor::visitFile() from do_from_local_dir() if we couldn't
find an .ini file.
If there's no .ini file found, we look at every package archive and
parse the version out of the archive filename.
This seems a really odd thing to do, as we've no idea about the
dependencies of these packages, so installing them is unlikely work well.
Removing all the setup.ini files from my package directory, the good
news is that WIN32_FIND_DATA just returns the filename, not a full
pathname, so this use of base() isn't needed, either.
The bad news is that setup then exits (this works ok in 2.882, so
something's got broken somewhere...)
I'm kind of tempted to remove this mis-feature.
next prev parent reply other threads:[~2017-10-26 16:14 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-25 15:50 Ken Brown
2017-10-25 19:23 ` Jon Turney
2017-10-25 20:16 ` Corinna Vinschen
2017-10-25 20:36 ` Jon Turney
2017-10-25 21:00 ` Corinna Vinschen
2017-10-26 16:14 ` Jon Turney
2017-10-26 16:14 ` Jon Turney [this message]
2017-10-26 17:04 ` Ken Brown
2017-10-26 17:20 ` Jon Turney
2017-10-26 17:42 ` Achim Gratz
2017-10-26 17:49 ` Jon Turney
2017-10-26 18:25 ` Achim Gratz
2017-10-27 8:47 ` Corinna Vinschen
2017-10-27 10:40 ` Achim Gratz
2017-10-27 13:44 ` Jon Turney
2017-10-27 15:20 ` Ken Brown
2017-10-27 16:28 ` Corinna Vinschen
2017-10-27 13:43 ` Jon Turney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03e94ec4-db88-8997-40a0-1c63b1a010bd@dronecode.org.uk \
--to=jon.turney@dronecode.org.uk \
--cc=cygwin-apps@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).