Does not closing a FileOutPutStream not write anything to the file?
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
add a comment |
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
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
add a comment |
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
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
java file fileoutputstream
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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)
.
1
flush
is done automatically as part of theclose
. 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, thereforeflush
should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13
add a comment |
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();
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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)
.
1
flush
is done automatically as part of theclose
. 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, thereforeflush
should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13
add a comment |
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)
.
1
flush
is done automatically as part of theclose
. 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, thereforeflush
should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13
add a comment |
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)
.
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)
.
edited Nov 23 '18 at 10:12
answered Nov 23 '18 at 10:09
oleg.cherednik
5,90321017
5,90321017
1
flush
is done automatically as part of theclose
. 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, thereforeflush
should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13
add a comment |
1
flush
is done automatically as part of theclose
. 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, thereforeflush
should help if resource is not closed correctly later.
– oleg.cherednik
Nov 23 '18 at 10:13
1
1
flush
is 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
flush
is 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
add a comment |
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();
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
add a comment |
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();
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
add a comment |
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();
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();
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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