public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Ken Brown <kbrown@cornell.edu>
To: cygwin-apps@cygwin.com
Subject: Re: setup and colons in filenames
Date: Thu, 26 Oct 2017 17:04:00 -0000	[thread overview]
Message-ID: <d23c2ef6-d33e-236e-cc95-fdf75fbbc2ae@cornell.edu> (raw)
In-Reply-To: <03e94ec4-db88-8997-40a0-1c63b1a010bd@dronecode.org.uk>

On 10/26/2017 12:14 PM, Jon Turney wrote:
> 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...)

What happens is that ScanFindVisitor::visitFile doesn't set various 
attributes of the packages it creates (such as SDesc).  This leads to a 
crash when the SolvableVersion methods (such as SDesc()) return null 
pointers that get dereferenced by PickView.

> I'm kind of tempted to remove this mis-feature.

I agree strongly.  I was about to write an email suggesting the same 
thing when I saw your mail.  Unless you're already working on it, I'll 
be glad to prepare a patch series that does this and also takes care of 
whatever is needed for supporting colons in installed.db

Ken

  reply	other threads:[~2017-10-26 17:04 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
2017-10-26 17:04     ` Ken Brown [this message]
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=d23c2ef6-d33e-236e-cc95-fdf75fbbc2ae@cornell.edu \
    --to=kbrown@cornell.edu \
    --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).