|
12 | 12 | * Used for both the console version and the Win32 GUI. A lot of code is for |
13 | 13 | * the console version only, so there is a lot of "#ifndef FEAT_GUI_MSWIN". |
14 | 14 | * |
15 | | - * Win32 (Windows NT and Windows 95) system-dependent routines. |
| 15 | + * Win32 system-dependent routines. |
16 | 16 | * Portions lifted from the Win32 SDK samples, the MSDOS-dependent code, |
17 | 17 | * NetHack 3.1.3, GNU Emacs 19.30, and Vile 5.5. |
18 | 18 | * |
@@ -7572,19 +7572,9 @@ mch_total_mem(int special UNUSED) |
7572 | 7572 |
|
7573 | 7573 | /* |
7574 | 7574 | * mch_wrename() works around a bug in rename (aka MoveFile) in |
7575 | | - * Windows 95: rename("foo.bar", "foo.bar~") will generate a |
7576 | | - * file whose short file name is "FOO.BAR" (its long file name will |
7577 | | - * be correct: "foo.bar~"). Because a file can be accessed by |
7578 | | - * either its SFN or its LFN, "foo.bar" has effectively been |
7579 | | - * renamed to "foo.bar", which is not at all what was wanted. This |
7580 | | - * seems to happen only when renaming files with three-character |
7581 | | - * extensions by appending a suffix that does not include ".". |
7582 | | - * Windows NT gets it right, however, with an SFN of "FOO~1.BAR". |
7583 | | - * |
7584 | | - * There is another problem, which isn't really a bug but isn't right either: |
| 7575 | + * Windows, the bug can be demonstrated with the following scenario: |
7585 | 7576 | * When renaming "abcdef~1.txt" to "abcdef~1.txt~", the short name can be |
7586 | | - * "abcdef~1.txt" again. This has been reported on Windows NT 4.0 with |
7587 | | - * service pack 6. Doesn't seem to happen on Windows 98. |
| 7577 | + * "abcdef~1.txt" again. |
7588 | 7578 | * |
7589 | 7579 | * Like rename(), returns 0 upon success, non-zero upon failure. |
7590 | 7580 | * Should probably set errno appropriately when errors occur. |
|
0 commit comments