[pacman-dev] Upgrading packages on case-insensitive filesystem

[Allan McRae]

On 04/02/15 01:02, Dan McGee wrote:
> On Tue, Feb 3, 2015 at 8:47 AM, David Macek <david.macek.0 at gmail.com> wrote:
>> Hi all.
>>
>> The issue is that pacman refuses to replace a file during package upgrade if the case of the file's name has changed between versions. The error displayed is this:
>>
>>> error: failed to commit transaction (conflicting files)
>>> example2: /path/to/file exists in filesystem
>>> Errors occurred, no packages were upgraded.
>>
>> I'm using pacman on Windows/NTFS (ported as part of the MSYS2 project). I'm not completely sure if the problem is in upstream pacman, or only in the ported one, but it's happened enough times to prompt me to ask you people. I don't fully understand _alpm_db_find_fileconflicts, but it seems that it can't discover that the conflicting file will be removed with the old version of the package before an actual conflict can occur.
>>
>> Would this be considered as a bug in pacman?
>>
>> For the whole log (not much longer) and example PKGBUILDs, look here: https://gist.github.com/elieux/8faaf423601d7ef01d0f
>>
>> Note that NTFS while is not case-sensitive by default, it is case-preserving.
> 
> This is a quick response without diving into the code, but from what I
> remember and can offer:
> 
> 1. If you could provide debug-level logs using `--debug`, that will
> make everything easier to troubleshoot. Your test case is very useful
> though, and can potentially even be turned into a pactest case later
> if this really wants to get solved.
> 2. "Does file exist" checks use either stat() or access(), which
> likely do the right thing with regards to case-sensitivity. However,
> pacman internally knows nothing about "are these two paths the same"
> characteristics of a particular filesystem. It simply uses strcmp() to
> see if they are identical.
> 3. There are a lot of assumptions related to #2 in the codebase, but
> in theory, we could look at a path, get filesystem info (statfs) for
> that path, and then decide if we should be case sensitive or
> insensitive when doing operations here.

We already check all mountpoints when checking space requirements. I'm
sure we can assess the case-sensitivity of the filesystem then.

> 4. Given the scope of #3, I wouldn't so much call this a bug as an
> unimplemented feature.
> 5. It is awesome that you are using pacman in a non-Arch setting! I
> think Allan/Dave/Andrew/current maintainers would definitely accept
> patches for better support for MSYS in "upstream" pacman as long as
> they don't have a negative impact on Arch usage, and this would also
> save you the burden of maintaining a large patchset and merging
> upstream all the time.

Sure  - send through any patches.  Although from memory, not a lot
needed changed when I last looked at your pathset it was not that big.

Allan