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

[Dan McGee]

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.
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.

-Dan, maintainer alumnus