Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug returning folder names when they can be considered 'numerical' #390

Open
baaym opened this issue Oct 28, 2019 · 1 comment
Open

Bug returning folder names when they can be considered 'numerical' #390

baaym opened this issue Oct 28, 2019 · 1 comment

Comments

@baaym
Copy link

baaym commented Oct 28, 2019

Hi all,

Given a folder name that could be considered a number, ImapClient will mangle that folder name in the case of leading zeroes.
For example: if I create a folder 012345, and execute a list_folders, ImapClient will return 12345.

The cause can be traced down to the atom function in response_parser.py. That function will check if a token in the response is a digit, and then cast the token to an int. When the int is later cast back to a str (in _proc_folder_list in imapclient.py), the leading zero has already been removed.

I'd be happy to provide a pull request for this bug, but since the atom function is a general-purpose function, I'm not sure what the best course of action is. Changing that behavior will likely have side effects on other parts of the code that do expect ints being returned.

@mjs
Copy link
Owner

mjs commented Nov 6, 2019

Ouch, good catch! I bet you could also see incorrect behaviour if a folder was called NIL :)

I think the right approach is to have a specialised function for handling folder list responses which doesn't use atom and just assumes everything is strings. It could still use TokenSource to generate tokens.

Does that sound reasonable? Are you prepared to have a go at the change?

mjs pushed a commit that referenced this issue Jul 1, 2020
* Prevent converting numbers with leading zeroes to int.
* But do treat a single 0 as an int.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants