下面是一个调用java的文件重命名方法的小程序:
- import java.io.*;
- public class FileRenameTest
- {
- public static void main(String[] args)
- {
- if(args.length<2)
- {
- System.out.println("Usage:java FileRenameTest <srcFileName> <targetFileName>");
- return ;
- }
- System.out.println("prepare to renaming file["+args[0]+"] to file["+args[1]+"]");
- boolean status= new File(args[0]).renameTo(new File(args[1]));
- System.out.println("status:"+String.valueOf(status));
- }
- }
在aix5.1或rhel6.1上准备把一个文件重命名到另一个文件系统中。最终执行的结果都是不能成功。
为什么通过系统命令mv却可以成功把一个文件重命名到另一个设备中呢?
在aix通过下列命令来观察此java程序执行过程系统内部的处理过程。
- truss -f -o rename.aix.truss java -cp . FileRenameTest origin.txt /tmp/origin.txt
在输出文件中找到下列重要信息。
- 8486994: 5308421: kwrite(1, " p r e p a r e t o r".., 61) = 61
- 8486994: 5308421: kwrite(1, "\n", 1) = 1
- 8486994: 5308421: rename("origin.txt", "/tmp/origin.txt") Err#18 EXDEV
- 8486994: 5308421: kwrite(1, " s t a t u s : f a l s e", 12) = 12
- 8486994: 5308421: kwrite(1, "\n", 1) = 1
从上面的内容可以看系统调用rename执行的结果是失败。Errno是18,也就是EXDEV错误。
在rhel6.1通过下列命令来观察此java程序执行过程系统内部的处理过程。
- strace -fxo rename.rh.strace java -cp . FileRenameTest origin.txt /tmp/origin.txt
在输出文件中可以找到下列重要信息。
- 19517 write(1, "prepare to renaming file[origin."..., 61) = 61
- 19517 write(1, "\n", 1) = 1
- 19517 rename("origin.txt", "/tmp/origin.txt") = -1 EXDEV (Invalid cross-device link)
- 19517 write(1, "status:false", 12) = 12
- 19517 write(1, "\n", 1) = 1
失败的原因与aix上失败的原因是一致的,都是非法的跨设备的操作。
我们来观察一下在aix及rhel上mv命令的执行过程。
通过下列命令来观察aix上mv的执行过程
- truss -f -o mv.aix.truss mv origin.txt /tmp/origin.txt
输出文件中可以看到下列重要信息。
- 6283516: 10338403: statx("origin.txt", 0x2FF22570, 176, 021) = 0
- 6283516: 10338403: statx("/tmp/origin.txt", 0x2FF22620, 176, 021) Err#2 ENOENT
- 6283516: 10338403: access("/tmp/origin.txt", 0) Err#2 ENOENT
- 6283516: 10338403: rename("origin.txt", "/tmp/origin.txt") Err#18 EXDEV
- 6283516: 10338403: statx("origin.txt", 0x2FF22570, 176, 021) = 0
- 6283516: 10338403: open("origin.txt", O_RDONLY|O_LARGEFILE) = 3
- 6283516: 10338403: statx("/tmp/origin.txt", 0x2FF22198, 176, 020) Err#2 ENOENT
- 6283516: 10338403: open("/tmp/origin.txt", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH) = 4
- 6283516: 10338403: fstatx(3, 0x2FF22248, 176, 020) = 0
- 6283516: 10338403: fstatx(4, 0x2FF222F8, 176, 020) = 0
- 6283516: 10338403: fstatfs(4, 0x2FF22430) = 0
- 6283516: 10338403: kread(3, " w w w w w w w\n\0\0\0\0".., 4096) = 8
- 6283516: 10338403: kwrite(4, " w w w w w w w\n", 8) = 8
- 6283516: 10338403: kread(3, " w w w w w w w\n\0\0\0\0".., 4096) = 0
- 6283516: 10338403: statx("origin.txt", 0x2FF22038, 176, 020) = 0
- 6283516: 10338403: __statxacl("origin.txt", 0x0000000000000000, 0x00000000, 0x2FF22028, 0x30003D08, 0x2FF22010) = 0
- 6283516: 10338403: chown("/tmp/origin.txt", 212, 1) = 0
- 6283516: 10338403: chmod("/tmp/origin.txt", 0100644) = 0
- 6283516: 10338403: __chxacl("/tmp/origin.txt", 0x0000000000000000, 0x0000000000000002, 0x41495843, 0, 06000036410) = 0
- 6283516: 10338403: listea("origin.txt", "", 0) Err#48 EFORMAT
- 6283516: 10338403: close(3) = 0
- 6283516: 10338403: close(4) = 0
- 6283516: 10338403: utimes("/tmp/origin.txt", 0x2FF22188) = 0
- 6283516: 10338403: unlink("origin.txt") = 0
mv命令执行过程大致如下:先调用rename,如果不成功则读原文件内容复制到新创建的目录文件中。再通过unlink取消原文件的链接数。如果原文件链接数为0,则会删除此文件。
在rhel上mv内部调用过程总体上与aix上是一致的。
不知道是基于什么原因考虑,java类库中renameTo方法的内部执行不与mv的执行保持一致。我觉得这是一个API实现上的瑕疵。