On 04/02/15 01:02, Dan McGee wrote: > On Tue, Feb 3, 2015 at 8:47 AM, David Macek <[email protected]> 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
