|
以前我一直以為File#renameTo(File)方法與OS下面的 move/mv
命令是相同的，可以達(dá)到改名、移動(dòng)文件的目的。不過后來經(jīng)常發(fā)現(xiàn)問題：File#renameTo(File)方法會(huì)返回失敗(false)，文件沒有移
動(dòng)，又查不出原因，再后來干脆棄用該方法，自己實(shí)現(xiàn)一個(gè)copy方法，問題倒是再也沒有出現(xiàn)過。
昨天老板同學(xué)又遇到這個(gè)問題，F(xiàn)ile#renameTo(File)方法在windows下面工作的好好的，在linux下偶爾又失靈了?；氐? 家我掃了一遍JDK中File#renameTo(File)方法的源代碼，發(fā)現(xiàn)它調(diào)用的是一個(gè)本地的方法(native method)，無(wú)法再跟蹤下去。網(wǎng)上有人說該方法在window下是正常的，在linux下面是不正常的。這個(gè)很難說通，SUN不可能搞出這種平臺(tái)不一 致的代碼出來啊。 后面在SUN的官方論壇上看到有人提到這個(gè)問題“works on windows, don't work on linux”，后面有人回復(fù)說是“file systems”不一樣。究竟怎么不一樣呢？還是沒有想出來... 后面在一個(gè)論壇里面發(fā)現(xiàn)了某人關(guān)于這個(gè)問題的闡述： 引用 In the
Unix'esque O/S's you cannot renameTo() across file systems. This
behavior is different than the Unix "mv" command. When crossing file
systems mv does a copy and delete which is what you'll have to do if
this is the case.
The same thing would happen on Windows if you tried to renameTo a different drive, i.e. C: -> D: 終于明白咯。 做個(gè)實(shí)驗(yàn)：
結(jié)果：
注意看結(jié)果，從C盤到E盤失敗了，從C盤到D盤成功了。因?yàn)槲业碾娔XC、D兩個(gè)盤是NTFS格式的，而E盤是FAT32格式的。所以從C到E就是上面文章所說的"file systems"不一樣。從C到D由于同是NTFS分區(qū)，所以不存在這個(gè)問題，當(dāng)然就成功了。 補(bǔ)充失敗原因： 1、在linux操作系統(tǒng)上在不同盤符之間renameTo也會(huì)失敗。典型的應(yīng)用場(chǎng)景就是從本地硬盤renameTo到mount的硬盤上或文件系統(tǒng)上。 2、在使用webwork的fileUpload攔截器的時(shí)候盡量不要使用execAndWait攔截器,兩個(gè)攔截器會(huì)開啟兩個(gè)線程，很可能會(huì)刪掉還沒有處理的臨時(shí)上傳文件文件而導(dǎo)致文件找不到。 3、在Windows下，如果目標(biāo)文件已經(jīng)存在，rename一般也會(huì)失敗，返回false。 果然是不能把File#renameTo(File)當(dāng)作move方法使用。 可以考慮使用apache組織的commons-io包里面的FileUtils#copyFile(File,File)和 FileUtils#copyFileToDirectory(File,File)方法實(shí)現(xiàn)copy的效果。至于刪除嘛，我想如果要求不是那么精確，可 以調(diào)用File#deleteOnExit()方法，在虛擬機(jī)終止的時(shí)候，刪除掉這個(gè)目錄或文件。 BTW:File是文件和目錄路徑名的抽象表示形式，所以有可能是目錄，千萬(wàn)小心。 |
|
|
