4

Why doesn't File.renameTo(...) create sub-directories contained in the destination file path?

For instance,

File source = new File(System.getProperty("user.dir") + 
                "/src/MyFolder/MyZipFolder.zip");
File dest = new File(System.getProperty("user.dir") + 
                "/src/MyOtherFolder/MyZipFolder.zip");
System.out.println(source.renameTo(dest));

Since MyOtherFolder does not exist, this will always return false. In order for this to work, I have to ensure that all sub-directories exist either by creating them programmatically(i.e. mkdirs()), or manually. Is there a reason why this functionality was not included in this method?

Moonbeam
  • 2,283
  • 1
  • 15
  • 17
  • Probably because I wouldn't consider that to be rename, I consider that to be 'move' :) – Kaj Jul 25 '11 at 13:55
  • @Kaj, It is a move, but it's sort-of bogus that one has to explicitly create all the sub-directories, or make sure they exist before you invoke this "convenience" method. – Moonbeam Jul 25 '11 at 13:56
  • I know what it does :) ... I just don't like that name, and that the functionallity is platform dependent, and that it only returns a boolean as a result. Well, there's much that I don't like about the File class. It should have been an interface to begin with. – Kaj Jul 25 '11 at 13:58
  • @Kaj, The platform dependency is not an issue in my case, since we're pretty much married to Windows :/. – Moonbeam Jul 25 '11 at 14:01
  • What's with the down-votes? People on here are ridiculous... – Moonbeam Jul 25 '11 at 14:23
  • Don't know, and I don't think your question is bad. – Kaj Jul 25 '11 at 14:25
  • Because not all filesystems have subdirectories. By spliting rename and makedir and move into seperate calls rename behaves on all filesystems the same, regardless whether it supports directories/subdirectories or not. Btw, the Java mkdir method does create all needed subdirectores, if I'm not mistaken. – Angel O'Sphere Jul 25 '11 at 15:24
  • @Angel, If you think you know so much, or that this question is just silly, why not make your comments an answer? – Moonbeam Jul 25 '11 at 15:33
  • Because there are alreay enough good answers ... – Angel O'Sphere Jul 25 '11 at 15:43
  • @Angel, Then why do you feel the need to comment? If the question has already been sufficiently answered, leave your derisive remarks to yourself. – Moonbeam Jul 25 '11 at 15:44
  • @Kaj - there is a lot wrong with the `File` class. However, while Sun/Oracle are progressively creating new file management APIs (in Java 7), we can expect the old `File` API to stay around "for ever" to maintain backwards compatibility. So you/we will have to live with it. The bottom line is that complaining about this might make you feel better, but it won't achieve anything. – Stephen C Jul 26 '11 at 02:48

4 Answers4

3

Why?

Possibly for consistency / compatibility with the APIs that typical operating systems and other programming language runtime libraries provide.

Possibly because it would be a bad idea to create the intermediate directories if the user didn't really mean this to happen; e.g. if he / she simply mistyped one of the directory names in the path.

But it is not really relevant. The bottom line is that this is the way that the renameTo method behaves.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • It would be nice if it were mentioned in the javadoc, you know? I don't see how it would be a bad idea to create the intermediate directories. This would just require that the programmer be more attentive. – Moonbeam Jul 25 '11 at 14:04
  • You are talking to the wrong people. If it concerns you, submit a bug report. – Stephen C Jul 25 '11 at 14:13
  • It's not really a bug, right? Just a failure to meet my expectations. I'm sure they have a valid reason for not including this functionality. I was just curious as to why, and why they didn't explicitly say to users of the API, "Hey guys, this doesn't create the sub-directories of the destination file path - sorry!". Or something along those lines. Maybe I'm just being ridiculous? Or at least that's how you're making me feel. – Moonbeam Jul 25 '11 at 14:16
  • 2
    @Moonbeam: I guess it's just you. You are pretty specific in your requirement (windows box, local drives) whereas libraries are tailored with "generic" use in mind. Surely, they can't have *everything* in the standard package/methods, no? As already mentioned, I personally wouldn't want `renameTo` to create destination directories if for some reason the move fails. Sure, they can allow the behaviour of `renameTo` to be made configurable by passing in a flag. But would that be worth it? IMO no. Of course, YMMV. – Sanjay T. Sharma Jul 25 '11 at 14:25
  • @Sanjay, If the move fails, why not perform a simple "cleanup"? Anyway, if the destination file you pass in `renameTo` contains sub-directories, it'll create those. I don't see why creating the folders prior is asking too much? Ah well...I suppose this question is just due to my inexperience. I understand that libraries are tailored with "generics" in mind. I'm not a complete tool. – Moonbeam Jul 25 '11 at 14:29
  • 1
    Like I said - if you feel it should behave differently submit a bug report labeled "feature request". If you feel that the javadoc is incorrect / incomplete, submit a bug report against the javadoc. I don't think you are being ridiculous ... but I don't think there's any point debating the "rightness" of the method's behaviour. – Stephen C Jul 25 '11 at 14:30
  • FWIW - it would be REALLY HARD to clean up if the `renameTo` created directories when it shouldn't. How do you know which directories it just created? (How do you know they weren't created by some other thread ... or application ... running at roughly the same time?) – Stephen C Jul 25 '11 at 14:35
  • @Stephen C, I meant for that to be part of `renameTo`. – Moonbeam Jul 25 '11 at 14:37
  • Perhaps you should adjust your "expectations" to the way hwo computers work since 60 years? How should a JavaDoc writer come to the idea that you don't know this or expect something different? – Angel O'Sphere Jul 25 '11 at 15:28
  • @Angel, I know you think you're being helpful, but you're not. You're just being condescending and rude. – Moonbeam Jul 25 '11 at 15:31
  • In my other comment I pointed out the reason, so what exactly do you find rude? APIs don'T work "as expected" if you read the Java Doc of "java.io.File.rename" then it is strongly adviced to "glance" over all otehr "java.io.File" methods as well. Then you had noticed the mkdir method e.g. and conlcuded by yourself that rename wont create subdirs. If you would gather experience by using a computer (and that means using a command shell likr bash occasionally) your "expectations" would become much more accurate. I don't see which of my points is rude, but my appologizes if you feel so ;D – Angel O'Sphere Jul 25 '11 at 15:47
  • 1
    @Moonbeam - it is **equally hard** (i.e. impossible) to implement in the Java libraries. If you think it is easy, try writing detailed pseudo-code for `renameTo` (e.g. in a separate Answer) and I'll critique it for you. – Stephen C Jul 25 '11 at 23:17
1

Creating sub-directories may be considered as unexpected side effect from other point of view. Are you sure everyone needs it implicitly?

Sergey Aslanov
  • 2,397
  • 15
  • 16
  • I suppose it's just an expectation. If I pass it a destination, I assume that it will do the work of creating any sub-directories that don't exist in that file path. If it were done implicitly, the resulting code would be much cleaner. – Moonbeam Jul 25 '11 at 14:03
1

The current File API isn't very well implemented in Java. There is a lot of functionality that would be desirable in a File API that isn't currently present such as move, copy and retrieving file metadata.

I don't think anyone will be able to give you an answer as to why the API is written as is. Probably a poor first draft that went live and couldn't be changed due to backwards compatibility issues.

These issue have been addressed in the upcoming Java 7. A entirely new API has been created to deal with files java.nio.file.Files.

demongolem
  • 9,474
  • 36
  • 90
  • 105
bstick12
  • 1,699
  • 12
  • 18
0

You have answers but I was thinking along the lines: A feature request to add a new method File.renameTo(File src, File destination, int makeDirs)

with three constants for makeDirs: 1) do not make sub folder(s)/ dirs 2) only make the final folder if it does not exist meaning if you specify /r1/r2/r3/file.extn then only make r3 if it does not exist, if r2 or any other does not exist then return false. 3) make all possible sub dirs

  • if its a OS that does not have sub folders then do as you do now
  • the old method would remain as is
Sukhdev
  • 36
  • 4