Issue 2716 encoding problem with directory 1.3.8

Title encoding problem with directory 1.3.8
Priority Status resolved
Milestone Resolved in 2.18.1
Superseder Nosy List ganesh
Assigned To

Created on 2024-02-19.10:36:02 by ganesh, last changed 2024-02-25.17:21:10 by noreply.

msg23747 (view) Author: ganesh Date: 2024-02-19.10:36:01
See discussion in patch2296 - it looks like darcs may be misusing
encodings and directory 1.3.8 has exposed that.
msg23751 (view) Author: ganesh Date: 2024-02-19.18:23:56
Short-term workaround is to constrain directory to <1.3.8 -
see patch2363.

That seems to build ok with GHC 9.8, but is presumably not going to play
well with package sets.
msg23761 (view) Author: ganesh Date: 2024-02-24.19:18:05
I had a stray allow-newer directory:base in my cabal.project.local,
so hadn't noticed that directory-1.3.7 doesn't actually officially
support GHC 9.8. That makes the short-term workaround (even) more
msg23764 (view) Author: ganesh Date: 2024-02-25.11:04:11
I've now spent some more time digging into this. Thanks to Vekhir
whose further comments on IRC helped point me in the right direction.

The basic problem is that if you have a patch with a name that contains
non-ASCII characters, you can't name a patch bundle file after that
patch when the filesystem encoding is set to ASCII.

The current implementation of darcs send makes this situation worse
because even if "-o" is used to override the bundle name, it tries
to calculate a filename named after the patch, and then throws it away
This involves using "doesFileExist" to check if the proposed name 

The behaviour change between directory 1.3.7 and 1.3.8 is that it now
throws when doesFileExist is called on an invalid filename, whereas
before it just returned False. But either way, if we got as far as
trying to write out the bundle with the name, it would fail with
any version of directory/GHC (directory isn't even involved in that).

As it happens, our tests only do "darcs send -o .." in the ASCII
encoding scenario, which is why they passed with directory 1.3.7
and fail with directory 1.3.8.

Overall I think there are two things to fix:
 1. Don't calculate the filename based on patch name unless
    actually needed
 2. If we do get an error calculating it, catch it and give the
    user a helpful error message suggesting they use "-o"

1 is a definite bug, 2 is more being helpful in the face of what
is theoretically a user error.
msg23765 (view) Author: ganesh Date: 2024-02-25.11:17:33
Note that this would also affect other commands like obliterate that
can write out patch bundles.
msg23772 (view) Author: noreply Date: 2024-02-25.17:21:10
The following patch sent by Ganesh Sittampalam <ganesh@earth.li> updated issue issue2716 with

Hash: 96e3c708e90aeff54ed56223b93138f156a3c08e
Author: Ganesh Sittampalam <ganesh@earth.li>
* resolve issue2716: calculate bundle names lazily

  Naming a patch bundle after a patch can fail if the patch
  name contains characters that aren't representable in the
  current filesystem encoding.

  Without this fix, it's not even possible to override the
  bundle name with -o, as the default name is calculated
Date User Action Args
2024-02-19 10:36:02ganeshcreate
2024-02-19 18:23:56ganeshsetmessages: + msg23751
2024-02-24 19:18:06ganeshsetmessages: + msg23761
2024-02-25 11:04:11ganeshsetmessages: + msg23764
2024-02-25 11:17:33ganeshsetmessages: + msg23765
2024-02-25 17:21:10noreplysetstatus: unknown -> resolved
messages: + msg23772
resolvedin: 2.18.1