[ https://issues.apache.org/jira/browse/IO-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835236#comment-13835236 ]
Joerg Schaible commented on IO-412: ----------------------------------- I like the idea, but not the class name nor the attempt to create a hidden file. You should probably create the name of the temporary file a from pattern like File.createTempFile(prefix,suffix) does. Currently your Javadoc claims to create a hidden file, but this is only true for Unix (and a hidden file in Windows can be created only with Java 7 and has nothing to do with the file name). Nevertheless such files are problematic if the process dies for some reason. IMHO a better sensible default (using an overloaded ctor) is what most ftp or download clients do and append a ".part" extension. Since you cannot define an own directory\(*) for the temporary file, you can safely assume that the move operation is atomic. Therefore I'd name this class AtomicFileOutputStream. *) I don't know if there's a way to ensure two directories to be on the same filesystem, otherwise you could even allow the specification of the temp directory. My 2¢. Jörg > AllOrNothingOutputStream > ------------------------ > > Key: IO-412 > URL: https://issues.apache.org/jira/browse/IO-412 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers > Reporter: BELUGA BEHR > Priority: Minor > Attachments: AllOrNothingFileOutputStream.java > > > Feel free to include this new FileOutputstream. No unit tests yet. Looking > for feedback at this point. > {code} > /** > * This is a wrapper around a FileOutputStream. It enables a stream to be > * written to a hidden file in a directory and only then renamed to the final > * destination if no exceptions occur. This implementation marks the file as > * hidden by pre-appending the file name with a period. If any exceptions > occur > * during writing, the hidden file will be deleted once close() is called. > This > * class takes advantage of {@link File#renameTo(File)}; therefore, many > aspects > * of the behavior of this class are inherently platform-dependent: The rename > * operation might not be able to move a file from one filesystem to another, > it > * might not be atomic, and it might not succeed if a file with the > destination > * abstract pathname already exists. This class is most useful when the rename > * operation is atomic. It is designed for the case when one process is > writing > * to a directory and another process is polling the directory for files to > * read. > */ > {code} -- This message was sent by Atlassian JIRA (v6.1#6144)