白左 发表于 2016-10-21 00:34

litel 发表于 2016-10-21 22:30

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

set a=352
set b=1

:start

echo %a%话_00%b%.png
call :plusone
if %b%==10 goto end

goto start


:plusone
set /A b=%b% + 1
EXIT /B


:end
pause

白左 发表于 2016-10-23 21:15

xburke 发表于 2016-10-23 21:48

本帖最后由 xburke 于 2016-10-23 21:56 编辑

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

白左 发表于 2016-10-23 22:03

xburke 发表于 2016-10-23 22:10

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

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

你试过重启吗

白左 发表于 2016-10-23 22:12

xburke 发表于 2016-10-23 22:22

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

http://ww2.sinaimg.cn/mw690/5c5a6abbjw1f92kf1jvgoj20px08qtbj.jpg

http://ww4.sinaimg.cn/mw690/5c5a6abbjw1f92kf1wct6j20ol05pmz5.jpg

白左 发表于 2016-10-23 22:31

xburke 发表于 2016-10-23 22:41

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

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

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

xburke 发表于 2016-10-23 22:48

本帖最后由 xburke 于 2016-10-23 22:58 编辑

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

能运行主贴中的复现脚本试试吗？ ...
不会是MFT出问题了吧……把这些png都复制到另一个硬盘或者另一个分区里再试试？
-------------

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

xburke 发表于 2016-10-23 22:55

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

白左 发表于 2016-10-23 23:24

月千一夜 发表于 2016-10-23 23:43

还能有这种bug， 长见识了

— from Sony D5803, Android 5.1.1

xburke 发表于 2016-10-23 23:56

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

似乎猜中一部分

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

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

noneoneone 发表于 2016-10-24 00:26

这也太奇葩了吧。。。

litel 发表于 2016-10-24 10:23

本帖最后由 litel 于 2016-10-24 10:26 编辑

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      
                )
)

白左 发表于 2016-10-24 17:18

xburke 发表于 2016-10-24 19:52

本帖最后由 xburke 于 2016-10-24 20:05 编辑

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

事实上这个问题前年在批处理之家问过， ...
额……这哥们的程序也有问题

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

也就是说，第一个函数得这么改
int by_findfirst(char *path){
    struct _finddata_t FileInfo;
    long Handle;
    int i=0;

    if((Handle=_findfirst(path,&FileInfo))!=-1L)
    {
      printf("%s\n",FileInfo.name);
      i++;
      while(!_findnext(Handle,&FileInfo)){
                        printf("%s\n",FileInfo.name);
                        i++;
                }
      _findclose(Handle);
    }

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



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

http://ww4.sinaimg.cn/large/5c5a6abbjw1f93lkx7h4ij20rc0g8dn5.jpg

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

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

ostcollector 发表于 2016-10-24 22:42

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

烈之斩 发表于 2016-10-24 23:33

本帖最后由 烈之斩 于 2016-10-24 10:39 编辑

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

首先这个问题不限于move，几乎所有命令都会有，只要你用*统配，包括dir：
c:\f>dir 352*
Volume in drive C has no label.
Volume Serial Number is B0B6-34B0

Directory of c:\f

10/24/201610:26 AM    <DIR>          352
10/24/201610:18 AM               0 353chap_005.png
10/24/201610:18 AM               0 352chap_001.png
10/24/201610:18 AM               0 352chap_002.png
10/24/201610:18 AM               0 352chap_003.png
10/24/201610:18 AM               0 352chap_004.png
10/24/201610:18 AM               0 352chap_005.png
10/24/201610:18 AM               0 352chap_006.png
               7 File(s)            0 bytes
               1 Dir(s)   5,609,127,936 bytes free
原因是该文件的8.3 name含有你选的字符：
c:\f>dir /x 352*
Volume in drive C has no label.
Volume Serial Number is B0B6-34B0

Directory of c:\f

10/24/201610:26 AM    <DIR>                     352
10/24/201610:18 AM               0 352808~1.PNG 353chap_005.png
10/24/201610:18 AM               0 352CHA~1.PNG 352chap_001.png
10/24/201610:18 AM               0 352CHA~2.PNG 352chap_002.png
10/24/201610:18 AM               0 352CHA~3.PNG 352chap_003.png
10/24/201610:18 AM               0 352CHA~4.PNG 352chap_004.png
10/24/201610:18 AM               0 352CD8~1.PNG 352chap_005.png
10/24/201610:18 AM               0 35E1B9~1.PNG 352chap_006.png
               7 File(s)            0 bytes
               1 Dir(s)   5,609,459,712 bytes free
至于为什么会变成352808~1.PNG参见维基的规则4，这里不再赘述。

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




endrollex 发表于 2016-10-24 23:42

本帖最后由 endrollex 于 2016-10-24 23:43 编辑

我试了下一楼的bat，一个GPT固态不正常（系统盘），一个MBR机械正常（非系统盘）
http://endrollex.com/upload/temp/2016/saraba1st_1341176.png

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

endrollex 发表于 2016-10-25 00:06

本帖最后由 endrollex 于 2016-10-25 00:18 编辑

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

endrollex.com/upload/temp/2016/saraba1st_1341176_2.png

烈之斩 发表于 2016-10-25 00:29

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

real_zyf 发表于 2016-10-25 02:47

没想到啊，竟然是8.3的锅

refo2613 发表于 2016-10-25 08:15

noneoneone 发表于 2016-10-25 08:57

居然是这上古遗留问题

—— 来自 Meizu PRO 5, Android 5.1

结夜野棠 发表于 2016-10-25 16:48

猴王阮病毒 发表于 2016-10-25 21:41

顺路同求个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 发表于 2016-10-25 22:04

别把系统盘的8dot3关了，会出问题的
页: [1]
查看完整版本: 【已解决】[Batch] 这bug是咋回事 (补充问题说明)