Does not closing a FileOutPutStream not write anything to the file?












-1














I have a function which writes the given input stream to a given output stream. Code below.



static void copyStream(InputStream is, OutputStream os) throws IOException {
byte buffer = new byte[4096];
int len;
try {
while ((len = is.read(buffer)) != -1) {
os.write(buffer, 0, len);
}
}
}


The above function is called from this function



public static void copyFile(File srcFile, File destFile) throws IOException {
FileInputStream fis = new FileInputStream(srcFile);
try {
FileOutputStream fos = new FileOutputStream(destFile);
try {
**copyStream**(fis, fos);
} finally {
if (fos != null)
fos.close();
}
} finally {
if (fis != null)
fis.close();
}
}


In this function, I am writing 4 MB at once. I use this function to copy images. Occasionally I see that the destination file is not created due to which an exception occurs while trying to read that file for future processing. I am guessing the culprit to be not closing the resources. Is my hypothesis good? What are the reasons why my function might fail? Please help










share|improve this question
























  • The file is created before this method is called so an exception here won't prevent the file being created.
    – Peter Lawrey
    Nov 23 '18 at 10:03










  • Issue or no issue, you should close your resources anyway.
    – Joakim Danielson
    Nov 23 '18 at 10:03










  • Agreed. I did close them. But I still was unable to figure out why accessing the copied file throws an exception occasionally( the issue is highly sporadic)
    – Bhargav
    Nov 23 '18 at 10:08










  • Could you provide caller method as well?
    – oleg.cherednik
    Nov 23 '18 at 10:14










  • Updated the question with calling function
    – Bhargav
    Nov 23 '18 at 10:19


















-1














I have a function which writes the given input stream to a given output stream. Code below.



static void copyStream(InputStream is, OutputStream os) throws IOException {
byte buffer = new byte[4096];
int len;
try {
while ((len = is.read(buffer)) != -1) {
os.write(buffer, 0, len);
}
}
}


The above function is called from this function



public static void copyFile(File srcFile, File destFile) throws IOException {
FileInputStream fis = new FileInputStream(srcFile);
try {
FileOutputStream fos = new FileOutputStream(destFile);
try {
**copyStream**(fis, fos);
} finally {
if (fos != null)
fos.close();
}
} finally {
if (fis != null)
fis.close();
}
}


In this function, I am writing 4 MB at once. I use this function to copy images. Occasionally I see that the destination file is not created due to which an exception occurs while trying to read that file for future processing. I am guessing the culprit to be not closing the resources. Is my hypothesis good? What are the reasons why my function might fail? Please help










share|improve this question
























  • The file is created before this method is called so an exception here won't prevent the file being created.
    – Peter Lawrey
    Nov 23 '18 at 10:03










  • Issue or no issue, you should close your resources anyway.
    – Joakim Danielson
    Nov 23 '18 at 10:03










  • Agreed. I did close them. But I still was unable to figure out why accessing the copied file throws an exception occasionally( the issue is highly sporadic)
    – Bhargav
    Nov 23 '18 at 10:08










  • Could you provide caller method as well?
    – oleg.cherednik
    Nov 23 '18 at 10:14










  • Updated the question with calling function
    – Bhargav
    Nov 23 '18 at 10:19
















-1












-1








-1







I have a function which writes the given input stream to a given output stream. Code below.



static void copyStream(InputStream is, OutputStream os) throws IOException {
byte buffer = new byte[4096];
int len;
try {
while ((len = is.read(buffer)) != -1) {
os.write(buffer, 0, len);
}
}
}


The above function is called from this function



public static void copyFile(File srcFile, File destFile) throws IOException {
FileInputStream fis = new FileInputStream(srcFile);
try {
FileOutputStream fos = new FileOutputStream(destFile);
try {
**copyStream**(fis, fos);
} finally {
if (fos != null)
fos.close();
}
} finally {
if (fis != null)
fis.close();
}
}


In this function, I am writing 4 MB at once. I use this function to copy images. Occasionally I see that the destination file is not created due to which an exception occurs while trying to read that file for future processing. I am guessing the culprit to be not closing the resources. Is my hypothesis good? What are the reasons why my function might fail? Please help










share|improve this question















I have a function which writes the given input stream to a given output stream. Code below.



static void copyStream(InputStream is, OutputStream os) throws IOException {
byte buffer = new byte[4096];
int len;
try {
while ((len = is.read(buffer)) != -1) {
os.write(buffer, 0, len);
}
}
}


The above function is called from this function



public static void copyFile(File srcFile, File destFile) throws IOException {
FileInputStream fis = new FileInputStream(srcFile);
try {
FileOutputStream fos = new FileOutputStream(destFile);
try {
**copyStream**(fis, fos);
} finally {
if (fos != null)
fos.close();
}
} finally {
if (fis != null)
fis.close();
}
}


In this function, I am writing 4 MB at once. I use this function to copy images. Occasionally I see that the destination file is not created due to which an exception occurs while trying to read that file for future processing. I am guessing the culprit to be not closing the resources. Is my hypothesis good? What are the reasons why my function might fail? Please help







java file fileoutputstream






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 23 '18 at 10:25









Rakesh

708616




708616










asked Nov 23 '18 at 10:01









Bhargav

181212




181212












  • The file is created before this method is called so an exception here won't prevent the file being created.
    – Peter Lawrey
    Nov 23 '18 at 10:03










  • Issue or no issue, you should close your resources anyway.
    – Joakim Danielson
    Nov 23 '18 at 10:03










  • Agreed. I did close them. But I still was unable to figure out why accessing the copied file throws an exception occasionally( the issue is highly sporadic)
    – Bhargav
    Nov 23 '18 at 10:08










  • Could you provide caller method as well?
    – oleg.cherednik
    Nov 23 '18 at 10:14










  • Updated the question with calling function
    – Bhargav
    Nov 23 '18 at 10:19




















  • The file is created before this method is called so an exception here won't prevent the file being created.
    – Peter Lawrey
    Nov 23 '18 at 10:03










  • Issue or no issue, you should close your resources anyway.
    – Joakim Danielson
    Nov 23 '18 at 10:03










  • Agreed. I did close them. But I still was unable to figure out why accessing the copied file throws an exception occasionally( the issue is highly sporadic)
    – Bhargav
    Nov 23 '18 at 10:08










  • Could you provide caller method as well?
    – oleg.cherednik
    Nov 23 '18 at 10:14










  • Updated the question with calling function
    – Bhargav
    Nov 23 '18 at 10:19


















The file is created before this method is called so an exception here won't prevent the file being created.
– Peter Lawrey
Nov 23 '18 at 10:03




The file is created before this method is called so an exception here won't prevent the file being created.
– Peter Lawrey
Nov 23 '18 at 10:03












Issue or no issue, you should close your resources anyway.
– Joakim Danielson
Nov 23 '18 at 10:03




Issue or no issue, you should close your resources anyway.
– Joakim Danielson
Nov 23 '18 at 10:03












Agreed. I did close them. But I still was unable to figure out why accessing the copied file throws an exception occasionally( the issue is highly sporadic)
– Bhargav
Nov 23 '18 at 10:08




Agreed. I did close them. But I still was unable to figure out why accessing the copied file throws an exception occasionally( the issue is highly sporadic)
– Bhargav
Nov 23 '18 at 10:08












Could you provide caller method as well?
– oleg.cherednik
Nov 23 '18 at 10:14




Could you provide caller method as well?
– oleg.cherednik
Nov 23 '18 at 10:14












Updated the question with calling function
– Bhargav
Nov 23 '18 at 10:19






Updated the question with calling function
– Bhargav
Nov 23 '18 at 10:19














2 Answers
2






active

oldest

votes


















0














I believe, that given InputStream and OutputStream installed correctly.
Add os.flush(); at the end. Sure, both streams should be closed in the caller as well.



As alternative, you could use Apache IO utils org.apache.commons.io.IOUtils.copy(InputStream input, OutputStream output).






share|improve this answer



















  • 1




    flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
    – Henry
    Nov 23 '18 at 10:12










  • Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
    – oleg.cherednik
    Nov 23 '18 at 10:13



















0














Yes you absolutely must close your destination file to ensure that all caches from the JVM through to the OS are flushed and the file is ready for a reader to consume.



Copying large files the way that you are doing is concise in code but inefficient in operation. Consider upgrading your code to use the more efficient NIO methods, documented here in a blog post. In case that blog disappears, here's the code:



Utility class:



public final class ChannelTools {
public static void fastChannelCopy(final ReadableByteChannel src, final WritableByteChannel dest) throws IOException {
final ByteBuffer buffer = ByteBuffer.allocateDirect(16 * 1024);
while (src.read(buffer) != -1) {
// prepare the buffer to be drained
buffer.flip();
// write to the channel, may block
dest.write(buffer);
// If partial transfer, shift remainder down
// If buffer is empty, same as doing clear()
buffer.compact();
}
// EOF will leave buffer in fill state
buffer.flip();
// make sure the buffer is fully drained.
while (buffer.hasRemaining()) {
dest.write(buffer);
}
}
}


Usage example with your InputStream and OutputStream:



// allocate the stream ... only for example
final InputStream input = new FileInputStream(inputFile);
final OutputStream output = new FileOutputStream(outputFile);
// get an channel from the stream
final ReadableByteChannel inputChannel = Channels.newChannel(input);
final WriteableByteChannel outputChannel = Channels.newChannel(output);
// copy the channels
ChannelTools.fastChannelCopy(inputChannel, outputChannel);
// closing the channels
inputChannel.close();
outputChannel.close()


There is also a more concise method documented in Wikipedia that achieves the same thing with less code:



// Getting file channels
FileChannel in = new FileInputStream(source).getChannel();
FileChannel out = new FileOutputStream(target).getChannel();

// JavaVM does its best to do this as native I/O operations.
in.transferTo(0, in.size(), out);

// Closing file channels will close corresponding stream objects as well.
out.close();
in.close();





share|improve this answer























  • Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
    – Bhargav
    Nov 23 '18 at 10:30






  • 1




    Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
    – Andy Brown
    Nov 23 '18 at 10:33












  • No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
    – Bhargav
    Nov 23 '18 at 11:52











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53444460%2fdoes-not-closing-a-fileoutputstream-not-write-anything-to-the-file%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














I believe, that given InputStream and OutputStream installed correctly.
Add os.flush(); at the end. Sure, both streams should be closed in the caller as well.



As alternative, you could use Apache IO utils org.apache.commons.io.IOUtils.copy(InputStream input, OutputStream output).






share|improve this answer



















  • 1




    flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
    – Henry
    Nov 23 '18 at 10:12










  • Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
    – oleg.cherednik
    Nov 23 '18 at 10:13
















0














I believe, that given InputStream and OutputStream installed correctly.
Add os.flush(); at the end. Sure, both streams should be closed in the caller as well.



As alternative, you could use Apache IO utils org.apache.commons.io.IOUtils.copy(InputStream input, OutputStream output).






share|improve this answer



















  • 1




    flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
    – Henry
    Nov 23 '18 at 10:12










  • Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
    – oleg.cherednik
    Nov 23 '18 at 10:13














0












0








0






I believe, that given InputStream and OutputStream installed correctly.
Add os.flush(); at the end. Sure, both streams should be closed in the caller as well.



As alternative, you could use Apache IO utils org.apache.commons.io.IOUtils.copy(InputStream input, OutputStream output).






share|improve this answer














I believe, that given InputStream and OutputStream installed correctly.
Add os.flush(); at the end. Sure, both streams should be closed in the caller as well.



As alternative, you could use Apache IO utils org.apache.commons.io.IOUtils.copy(InputStream input, OutputStream output).







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 23 '18 at 10:12

























answered Nov 23 '18 at 10:09









oleg.cherednik

5,90321017




5,90321017








  • 1




    flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
    – Henry
    Nov 23 '18 at 10:12










  • Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
    – oleg.cherednik
    Nov 23 '18 at 10:13














  • 1




    flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
    – Henry
    Nov 23 '18 at 10:12










  • Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
    – oleg.cherednik
    Nov 23 '18 at 10:13








1




1




flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
– Henry
Nov 23 '18 at 10:12




flushis done automatically as part of the close. No need to do it explicitly unless you want to flush without closing (yet).
– Henry
Nov 23 '18 at 10:12












Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13




Yes, but I do not see caller method, therefore flush should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13













0














Yes you absolutely must close your destination file to ensure that all caches from the JVM through to the OS are flushed and the file is ready for a reader to consume.



Copying large files the way that you are doing is concise in code but inefficient in operation. Consider upgrading your code to use the more efficient NIO methods, documented here in a blog post. In case that blog disappears, here's the code:



Utility class:



public final class ChannelTools {
public static void fastChannelCopy(final ReadableByteChannel src, final WritableByteChannel dest) throws IOException {
final ByteBuffer buffer = ByteBuffer.allocateDirect(16 * 1024);
while (src.read(buffer) != -1) {
// prepare the buffer to be drained
buffer.flip();
// write to the channel, may block
dest.write(buffer);
// If partial transfer, shift remainder down
// If buffer is empty, same as doing clear()
buffer.compact();
}
// EOF will leave buffer in fill state
buffer.flip();
// make sure the buffer is fully drained.
while (buffer.hasRemaining()) {
dest.write(buffer);
}
}
}


Usage example with your InputStream and OutputStream:



// allocate the stream ... only for example
final InputStream input = new FileInputStream(inputFile);
final OutputStream output = new FileOutputStream(outputFile);
// get an channel from the stream
final ReadableByteChannel inputChannel = Channels.newChannel(input);
final WriteableByteChannel outputChannel = Channels.newChannel(output);
// copy the channels
ChannelTools.fastChannelCopy(inputChannel, outputChannel);
// closing the channels
inputChannel.close();
outputChannel.close()


There is also a more concise method documented in Wikipedia that achieves the same thing with less code:



// Getting file channels
FileChannel in = new FileInputStream(source).getChannel();
FileChannel out = new FileOutputStream(target).getChannel();

// JavaVM does its best to do this as native I/O operations.
in.transferTo(0, in.size(), out);

// Closing file channels will close corresponding stream objects as well.
out.close();
in.close();





share|improve this answer























  • Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
    – Bhargav
    Nov 23 '18 at 10:30






  • 1




    Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
    – Andy Brown
    Nov 23 '18 at 10:33












  • No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
    – Bhargav
    Nov 23 '18 at 11:52
















0














Yes you absolutely must close your destination file to ensure that all caches from the JVM through to the OS are flushed and the file is ready for a reader to consume.



Copying large files the way that you are doing is concise in code but inefficient in operation. Consider upgrading your code to use the more efficient NIO methods, documented here in a blog post. In case that blog disappears, here's the code:



Utility class:



public final class ChannelTools {
public static void fastChannelCopy(final ReadableByteChannel src, final WritableByteChannel dest) throws IOException {
final ByteBuffer buffer = ByteBuffer.allocateDirect(16 * 1024);
while (src.read(buffer) != -1) {
// prepare the buffer to be drained
buffer.flip();
// write to the channel, may block
dest.write(buffer);
// If partial transfer, shift remainder down
// If buffer is empty, same as doing clear()
buffer.compact();
}
// EOF will leave buffer in fill state
buffer.flip();
// make sure the buffer is fully drained.
while (buffer.hasRemaining()) {
dest.write(buffer);
}
}
}


Usage example with your InputStream and OutputStream:



// allocate the stream ... only for example
final InputStream input = new FileInputStream(inputFile);
final OutputStream output = new FileOutputStream(outputFile);
// get an channel from the stream
final ReadableByteChannel inputChannel = Channels.newChannel(input);
final WriteableByteChannel outputChannel = Channels.newChannel(output);
// copy the channels
ChannelTools.fastChannelCopy(inputChannel, outputChannel);
// closing the channels
inputChannel.close();
outputChannel.close()


There is also a more concise method documented in Wikipedia that achieves the same thing with less code:



// Getting file channels
FileChannel in = new FileInputStream(source).getChannel();
FileChannel out = new FileOutputStream(target).getChannel();

// JavaVM does its best to do this as native I/O operations.
in.transferTo(0, in.size(), out);

// Closing file channels will close corresponding stream objects as well.
out.close();
in.close();





share|improve this answer























  • Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
    – Bhargav
    Nov 23 '18 at 10:30






  • 1




    Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
    – Andy Brown
    Nov 23 '18 at 10:33












  • No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
    – Bhargav
    Nov 23 '18 at 11:52














0












0








0






Yes you absolutely must close your destination file to ensure that all caches from the JVM through to the OS are flushed and the file is ready for a reader to consume.



Copying large files the way that you are doing is concise in code but inefficient in operation. Consider upgrading your code to use the more efficient NIO methods, documented here in a blog post. In case that blog disappears, here's the code:



Utility class:



public final class ChannelTools {
public static void fastChannelCopy(final ReadableByteChannel src, final WritableByteChannel dest) throws IOException {
final ByteBuffer buffer = ByteBuffer.allocateDirect(16 * 1024);
while (src.read(buffer) != -1) {
// prepare the buffer to be drained
buffer.flip();
// write to the channel, may block
dest.write(buffer);
// If partial transfer, shift remainder down
// If buffer is empty, same as doing clear()
buffer.compact();
}
// EOF will leave buffer in fill state
buffer.flip();
// make sure the buffer is fully drained.
while (buffer.hasRemaining()) {
dest.write(buffer);
}
}
}


Usage example with your InputStream and OutputStream:



// allocate the stream ... only for example
final InputStream input = new FileInputStream(inputFile);
final OutputStream output = new FileOutputStream(outputFile);
// get an channel from the stream
final ReadableByteChannel inputChannel = Channels.newChannel(input);
final WriteableByteChannel outputChannel = Channels.newChannel(output);
// copy the channels
ChannelTools.fastChannelCopy(inputChannel, outputChannel);
// closing the channels
inputChannel.close();
outputChannel.close()


There is also a more concise method documented in Wikipedia that achieves the same thing with less code:



// Getting file channels
FileChannel in = new FileInputStream(source).getChannel();
FileChannel out = new FileOutputStream(target).getChannel();

// JavaVM does its best to do this as native I/O operations.
in.transferTo(0, in.size(), out);

// Closing file channels will close corresponding stream objects as well.
out.close();
in.close();





share|improve this answer














Yes you absolutely must close your destination file to ensure that all caches from the JVM through to the OS are flushed and the file is ready for a reader to consume.



Copying large files the way that you are doing is concise in code but inefficient in operation. Consider upgrading your code to use the more efficient NIO methods, documented here in a blog post. In case that blog disappears, here's the code:



Utility class:



public final class ChannelTools {
public static void fastChannelCopy(final ReadableByteChannel src, final WritableByteChannel dest) throws IOException {
final ByteBuffer buffer = ByteBuffer.allocateDirect(16 * 1024);
while (src.read(buffer) != -1) {
// prepare the buffer to be drained
buffer.flip();
// write to the channel, may block
dest.write(buffer);
// If partial transfer, shift remainder down
// If buffer is empty, same as doing clear()
buffer.compact();
}
// EOF will leave buffer in fill state
buffer.flip();
// make sure the buffer is fully drained.
while (buffer.hasRemaining()) {
dest.write(buffer);
}
}
}


Usage example with your InputStream and OutputStream:



// allocate the stream ... only for example
final InputStream input = new FileInputStream(inputFile);
final OutputStream output = new FileOutputStream(outputFile);
// get an channel from the stream
final ReadableByteChannel inputChannel = Channels.newChannel(input);
final WriteableByteChannel outputChannel = Channels.newChannel(output);
// copy the channels
ChannelTools.fastChannelCopy(inputChannel, outputChannel);
// closing the channels
inputChannel.close();
outputChannel.close()


There is also a more concise method documented in Wikipedia that achieves the same thing with less code:



// Getting file channels
FileChannel in = new FileInputStream(source).getChannel();
FileChannel out = new FileOutputStream(target).getChannel();

// JavaVM does its best to do this as native I/O operations.
in.transferTo(0, in.size(), out);

// Closing file channels will close corresponding stream objects as well.
out.close();
in.close();






share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 23 '18 at 10:26

























answered Nov 23 '18 at 10:20









Andy Brown

5,17721640




5,17721640












  • Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
    – Bhargav
    Nov 23 '18 at 10:30






  • 1




    Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
    – Andy Brown
    Nov 23 '18 at 10:33












  • No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
    – Bhargav
    Nov 23 '18 at 11:52


















  • Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
    – Bhargav
    Nov 23 '18 at 10:30






  • 1




    Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
    – Andy Brown
    Nov 23 '18 at 10:33












  • No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
    – Bhargav
    Nov 23 '18 at 11:52
















Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
– Bhargav
Nov 23 '18 at 10:30




Thank you for the answer. I understand the importance of flip and compact. But why will the copy fail so sporadically? I mean this function fails once in 10000 times may be. What is the reason it could fail?
– Bhargav
Nov 23 '18 at 10:30




1




1




Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
– Andy Brown
Nov 23 '18 at 10:33






Is your reader synchronized with the writer? How does the reader know when the writer has finished completely? If it's monitoring a directory for files appearing then you have a potential race condition.
– Andy Brown
Nov 23 '18 at 10:33














No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
– Bhargav
Nov 23 '18 at 11:52




No, it is not within the same flow we write a file to a new location and try to read it somewhere down the line in the code. I guess you are right it is a race condition. Thank you for your time
– Bhargav
Nov 23 '18 at 11:52


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53444460%2fdoes-not-closing-a-fileoutputstream-not-write-anything-to-the-file%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Trompette piccolo

How do I get these specific pathlines to nodes?

What visual should I use to simply compare current year value vs last year in Power BI desktop