【已解决】[Batch] 这bug是咋回事 (补充问题说明)

litel

不需要for那么高级的东西啦

1. @Echo off
   
2. 
   
3. set a=352
   
4. set b=1
   
5. 
   
6. :start
   
7. 
   
8. echo %a%话_00%b%.png
   
9. call :plusone
   
10. if %b%==10 goto end
    
11. 
    
12. goto start
    
13. 
    
14. 
    
15. :plusone
    
16. set /A b=%b% + 1
    
17. EXIT /B
    
18. 
    
19. 
    
20. :end
    
21. pause

复制代码

xburke

奇怪，我起了355话_003.png 和 352话_003.png 这两个文件名，用move命令，没问题啊
莫非文件要足够多才能复现

xburke

白左 发表于 2016-10-23 22:03
是的，至少要001到005
如果从001到050,353、354、355话都能出现错乱

弄了001-005，试了下还是没问题……

你试过重启吗

xburke

白左 发表于 2016-10-23 22:12
能提供你的环境和测试代码吗
这个bug还是win7时代遇到的，系统和机器都换过了依然能够复现，和重启无关 ...

xburke

白左 发表于 2016-10-23 22:31
按照你的方法我这里会额外拉一张355，总共6个文件

能运行主贴中的复现脚本试试吗？ ...

运行了，没问题啊，每个文件夹里5个文件，都是对应的

xburke

白左 发表于 2016-10-23 22:31
按照你的方法我这里会额外拉一张355，总共6个文件

能运行主贴中的复现脚本试试吗？ ...

不会是MFT出问题了吧……把这些png都复制到另一个硬盘或者另一个分区里再试试？
-------------

哦，机器也换过……那就不是这个问题了

xburke

还有可以用powershell的move试试，我这边的也没问题

月千一夜

还能有这种bug， 长见识了

— from Sony D5803, Android 5.1.1

xburke

白左 发表于 2016-10-23 23:24
不不不，迷之击中关键了，虽然机器是换过，但是硬盘确实是唯一一直用下来没变过的
所有分区都试了一下，没 ...

似乎猜中一部分

还有就是要看看是不是sata线有问题了，不过这没法解释ps不会出问题，以及三块硬盘出的问题都一样……

把文件备份一下，跑个chkdsk看看吧

noneoneone

这也太奇葩了吧。。。

litel

cmd里面不要用 * 匹配。。。总会得到一些奇葩结果。

最后一段改为


for /l %%i in (%chStart%,1,%chEnd%) do (
        for /l %%p in (1,1,5) do (
                        echo mkdir %%i
                        echo move %%i_00%%p.png %%i        
                )
)

xburke

白左 发表于 2016-10-24 17:18
今天试了下公司的电脑，回头又看了下本机的硬盘，情况大概是这样

事实上这个问题前年在批处理之家问过， ...

额……这哥们的程序也有问题

_findfirst的时候已经找到第一个文件了，这时就应该输出和开始计数，而不是只统计_findnext

也就是说，第一个函数得这么改

1. 
   
2. int by_findfirst(char *path){
   
3.     struct _finddata_t FileInfo;
   
4.     long Handle;
   
5.     int i=0;
   
6. 
   
7.     if((Handle=_findfirst(path,&FileInfo))!=-1L)
   
8.     {
   
9.         printf("%s\n",FileInfo.name);
   
10.         i++;
    
11.         while(!_findnext(Handle,&FileInfo)){
    
12.                         printf("%s\n",FileInfo.name);
    
13.                         i++;
    
14.                 }
    
15.         _findclose(Handle);
    
16.     }
    
17. 
    
18.     return i;
    
19. }
    

复制代码

第二个函数类似
如此一来，_findfirst和FindNextFile 的结果和dir是完全一致的，此其一



另一个方面，代码经如上修改后在我的机器上的测试显示，这三个函数的处理结果完全没有问题，见下图，此其二



所以只能猜测也许是那哥们的硬盘跟你的出了类似的问题……
或者有这种可能性，你的png文件本身在硬盘的存储有问题，而你是把这些文件拷贝到各块硬盘上进行测试的（我的猜测），所以在大多数硬盘能复现？当然如果你用于测试的png文件都是新建的，那当我没说

对程序的debug在机油的帮助下完成，特此感谢

ostcollector

这个错乱是怎么回事。。。
chkdsk应该不是这么报告的吧

烈之斩

随便帮LZ搜了下，知道为啥了。（关键词：command line wildcard wrong file，第一个）

首先这个问题不限于move，几乎所有命令都会有，只要你用*统配，包括dir：

1. 
   
2. c:\f>dir 352*
   
3. Volume in drive C has no label.
   
4. Volume Serial Number is B0B6-34B0
   
5. 
   
6. Directory of c:\f
   
7. 
   
8. 10/24/2016  10:26 AM    <DIR>          352
   
9. 10/24/2016  10:18 AM                 0 353chap_005.png
   
10. 10/24/2016  10:18 AM                 0 352chap_001.png
    
11. 10/24/2016  10:18 AM                 0 352chap_002.png
    
12. 10/24/2016  10:18 AM                 0 352chap_003.png
    
13. 10/24/2016  10:18 AM                 0 352chap_004.png
    
14. 10/24/2016  10:18 AM                 0 352chap_005.png
    
15. 10/24/2016  10:18 AM                 0 352chap_006.png
    
16.                7 File(s)              0 bytes
    
17.                1 Dir(s)   5,609,127,936 bytes free
    

复制代码

原因是该文件的8.3 name含有你选的字符：

1. 
   
2. c:\f>dir /x 352*
   
3. Volume in drive C has no label.
   
4. Volume Serial Number is B0B6-34B0
   
5. 
   
6. Directory of c:\f
   
7. 
   
8. 10/24/2016  10:26 AM    <DIR>                       352
   
9. 10/24/2016  10:18 AM                 0 352808~1.PNG 353chap_005.png
   
10. 10/24/2016  10:18 AM                 0 352CHA~1.PNG 352chap_001.png
    
11. 10/24/2016  10:18 AM                 0 352CHA~2.PNG 352chap_002.png
    
12. 10/24/2016  10:18 AM                 0 352CHA~3.PNG 352chap_003.png
    
13. 10/24/2016  10:18 AM                 0 352CHA~4.PNG 352chap_004.png
    
14. 10/24/2016  10:18 AM                 0 352CD8~1.PNG 352chap_005.png
    
15. 10/24/2016  10:18 AM                 0 35E1B9~1.PNG 352chap_006.png
    
16.                7 File(s)              0 bytes
    
17.                1 Dir(s)   5,609,459,712 bytes free
    

复制代码

至于为什么会变成352808~1.PNG参见维基的规则4，这里不再赘述。

至于为什么每个硬盘不一样，交给lz自己研究了。大概是里面提到的“undocumented hash”和磁盘路径有关。

endrollex

我试了下一楼的bat，一个GPT固态不正常（系统盘），一个MBR机械正常（非系统盘）


但我把“话”字去掉，就正常了，可能是字符问题（txt默认ANSI 编码），会让*匹配错误，跟3楼一样
如果bat 用 UTF-8 without BOM 编码，会出现另外一种错误

endrollex

21的解释没错，有的硬盘不会短命名HASH，就不会出现问题
我的C盘是TOSHIBA THNSNJ128GCSU，有短命名
D盘是ST500DM002-1BD142，无短命名

烈之斩

直接用 fsutil.exe behavior set disable8dot3 1 禁用所有ntfs盘的8.3就行了。

real_zyf

没想到啊，竟然是8.3的锅

noneoneone

居然是这上古遗留问题

—— 来自 Meizu PRO 5, Android 5.1

猴王阮病毒

顺路同求个bat

环境如下
一个叫WWW的文件夹
下面有001，002，003，004.....xxx个子文件夹
每个子文件夹里有4个不同名字不同类型的文件，都叫J.m， K.n,   S.o,  U.p等
现在我需要把每个子文件夹里的所有4个文件，都做以下处理：
第一步，比如001文件夹下，
J.m， K.n,   S.o,  U.p
全部改名为
001.m ， 001.n  ， 001.o   ， 001.p
第二步，001里的4个文件全部拿出来扔到WWW文件夹里

这样重复
就是在WWW文件夹下，全是
001.m ， 001.n  ， 001.o   ， 001.p
002.m ， 002.n  ， 002.o   ， 002.p
*               *             *              *
*               *             *              *
*               *             *              *
xxx.m ， xxx.n  ， xxx.o   ， xxx.p

这样的情况

hein

别把系统盘的8dot3关了，会出问题的