Comment 14 for bug 311818
Revision history for this message
| poy (poy) wrote Re: case-sensitivity in Unix systems | #14 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
the impact of disobeying the spec? i'd rather not even think about it. producing invalid file lists could break various clients that implement the ADC spec to the letter - or they may simply completely discard such file lists. i don't know why the spec explicitly spells this out, but it does and has to be obeyed to.
instead of thinking of fictive scenarios based on a client that would produce invalid file lists, or code changes, the first focus of this discussion should be how to best ammend our current use of the protocol to allow case-insensitive dupes in a file list. here are some possibilities that spring to mind:
- add a new extension, with its own fourcc and all. this is a sure-fire way of not breaking anything and being perfectly compliant with the current spec. one flipside of this is that a client implementing this extension would have to manage 2 file lists, one with case-insensitive dupes and one without.
- use a new root in the file list, similar to the current "/", for example "/v2/" or "/extended/".
- change the version of the file list (the "version" parameter of the first tag) to "1.1" or "2.0".
- add a note in the ADC "recommandation" document saying that that particular phrase has been deprecated and should be ignored. but i doubt the ADC maintainers would allow such a frivolity...
- dynamically modify the name of a case-insensitive dupe before sharing it, for example by appending " (1)", " (2)", etc or underscores. this allows for no compat change; however, it could be bothersome to manage code-wise. this would be my favorite possibility if it were at all doable.
i don't know how practical these design changes are, and there may be other possibilities, but one has to be chosen for sure before thinking of going further.
regarding endator's last comment: no, DC++ only shares one of the files if 2 files with the same name but a different TTH are found in the same virtual directory. it would be nice if the solution adopted in this thread for case-insensitive dupes could also be generally applied to name dupes in merged directories.