Revision b2732e609785dbaa8f13e6c8d80f8e1eb0baae8f authored by Johannes Schindelin on 17 December 2019, 12:16:34 UTC, committed by Johannes Schindelin on 09 January 2020, 11:54:30 UTC
In 224c7d70fa1 (mingw: only test index entries for backslashes, not tree entries, 2019-12-31), we relaxed the check for backslashes in tree entries to check only index entries. However, the code change was incorrect: it was added to `add_index_entry_with_check()`, not to `add_index_entry()`, so under certain circumstances it was possible to side-step the protection. Besides, the description of that commit purported that all index entries would be checked when in fact they were only checked when being added to the index (there are code paths that do not do that, constructing "transient" index entries). In any case, it was pointed out in one insightful review at https://github.com/git-for-windows/git/pull/2437#issuecomment-566771835 that it would be a much better idea to teach `verify_path()` to perform the check for a backslash. This is safer, even if it comes with two notable drawbacks: - `verify_path()` cannot say _what_ is wrong with the path, therefore the user will no longer be told that there was a backslash in the path, only that the path was invalid. - The `git apply` command also calls the `verify_path()` function, and might have been able to handle Windows-style paths (i.e. with backslashes instead of forward slashes). This will no longer be possible unless the user (temporarily) sets `core.protectNTFS=false`. Note that `git add <windows-path>` will _still_ work because `normalize_path_copy_len()` will convert the backslashes to forward slashes before hitting the code path that creates an index entry. The clear advantage is that `verify_path()`'s purpose is to check the validity of the file name, therefore we naturally tap into all the code paths that need safeguarding, also implicitly into future code paths. The benefits of that approach outweigh the downsides, so let's move the check from `add_index_entry_with_check()` to `verify_path()`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
1 parent 7a6a90c
prio-queue.h
#ifndef PRIO_QUEUE_H
#define PRIO_QUEUE_H
/*
* A priority queue implementation, primarily for keeping track of
* commits in the 'date-order' so that we process them from new to old
* as they are discovered, but can be used to hold any pointer to
* struct. The caller is responsible for supplying a function to
* compare two "things".
*
* Alternatively, this data structure can also be used as a LIFO stack
* by specifying NULL as the comparison function.
*/
/*
* Compare two "things", one and two; the third parameter is cb_data
* in the prio_queue structure. The result is returned as a sign of
* the return value, being the same as the sign of the result of
* subtracting "two" from "one" (i.e. negative if "one" sorts earlier
* than "two").
*/
typedef int (*prio_queue_compare_fn)(const void *one, const void *two, void *cb_data);
struct prio_queue_entry {
unsigned ctr;
void *data;
};
struct prio_queue {
prio_queue_compare_fn compare;
unsigned insertion_ctr;
void *cb_data;
int alloc, nr;
struct prio_queue_entry *array;
};
/*
* Add the "thing" to the queue.
*/
void prio_queue_put(struct prio_queue *, void *thing);
/*
* Extract the "thing" that compares the smallest out of the queue,
* or NULL. If compare function is NULL, the queue acts as a LIFO
* stack.
*/
void *prio_queue_get(struct prio_queue *);
/*
* Gain access to the "thing" that would be returned by
* prio_queue_get, but do not remove it from the queue.
*/
void *prio_queue_peek(struct prio_queue *);
void clear_prio_queue(struct prio_queue *);
/* Reverse the LIFO elements */
void prio_queue_reverse(struct prio_queue *);
#endif /* PRIO_QUEUE_H */
Computing file changes ...
