• Post Reply Bookmark Topic Watch Topic
  • New Topic

Check if a file copying (writting) is completed in Java on Linux machine  RSS feed

 
abhinas raj
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi All,

I have written a piece of code to check that a file copy has been completed,
but the problem is that this code works only on windows not on Linux. i need it working for
both windows and Linux.

here the logic is being used that.
when the file is still being copied then if we try to read it, an Exception is thrown
and once copy is completed then if we read then exception is not thrown, and then we come to know that file copying is complted.



i need help to make this code work on Linux machine also.

Thank you in advance.
 
Liutauras Vilda
Marshal
Posts: 4665
320
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
abhinas raj,

Please check exact instructions how to UseCodeTags (<-- link to open and read). Everytime you post code, please use them.
 
abhinas raj
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Liutauras Vilda wrote:abhinas raj,

Please check exact instructions how to UseCodeTags (<-- link to open and read). Everytime you post code, please use them.


ok Thank you for the information
 
Stephan van Hulst
Saloon Keeper
Posts: 7817
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Writing code like this is a really bad idea. Logic shouldn't depend on whether an exception is thrown. I'm also not convinced that being able to open a file is a reliable indicator for a file transfer to have occurred.

I don't think there's a good reason to do this. If the copy is initiated by your own application, you can just block until the operation is done. If the copy is done externally, you have no way to know whether it occurred successfully, without trying to use the file like you would normally.

Maybe you can explain your use case.
 
Bhushan Bhawsar
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also don't think the exception based logic is good. If you have control of the copy file code, then you can create an empty file (like <FILENAME>.rdy) after the copy is completed. In your copyCompleted method you can poll for this .rdy file. If it exists, then the copy is completed. I also faced similar problem in past and this logic worked for me.
 
abhinas raj
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Writing code like this is a really bad idea. Logic shouldn't depend on whether an exception is thrown. I'm also not convinced that being able to open a file is a reliable indicator for a file transfer to have occurred.

I don't think there's a good reason to do this. If the copy is initiated by your own application, you can just block until the operation is done. If the copy is done externally, you have no way to know whether it occurred successfully, without trying to use the file like you would normally.

Maybe you can explain your use case.


Thank you for the reply Stephan.

here the use case is some one will copy the file manually in a location, now my application need to know that when that file copy has been completed.
1) checking the size of the every time file, and if its size is not changed after some time, then we will assume file is copied
2) checking the file modified time every time.
these two methods will not work as per our aspectations.

we need another solution for this.

 
abhinas raj
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bhushan Bhawsar wrote:I also don't think the exception based logic is good. If you have control of the copy file code, then you can create an empty file (like <FILENAME>.rdy) after the copy is completed. In your copyCompleted method you can poll for this .rdy file. If it exists, then the copy is completed. I also faced similar problem in past and this logic worked for me.


Thank you for your reply.

please read my latest comment on the post, if you have any other solution please do let me know.
 
Stephan van Hulst
Saloon Keeper
Posts: 7817
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You haven't explained why your application needs to know this.
 
fred rosenberger
lowercase baba
Bartender
Posts: 12542
48
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I understand it, Unix doesn't really lock files like this. I can open two vi sessions to the same file. If I make a save in session 1, the 2nd has no idea about that change. When I then save the file in my second vi session, the first change is lost.

I believe you can implement some file locking methodologies, but they are...quirky...at best. Most sysAdmins I've worked just don't bother.

You say:
) checking the size of the every time file, and if its size is not changed after some time, then we will assume file is copied
2) checking the file modified time every time.

these two methods will not work as per our aspectations.

we need another solution for this.

You don't say WHY the above won't work. We use both of the above in my work environment with tremendous success.

Tell us what your requirements ARE, and WHY the above won't work, and maybe we can help.
 
fred rosenberger
lowercase baba
Bartender
Posts: 12542
48
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bhushan Bhawsar wrote:If you have control of the copy file code, then you can create an empty file (like <FILENAME>.rdy) after the copy is completed.

Another solution, if you have control of the copy, is to make the copy with a temporary name. Then when THAT program is done, you rename the file to the correct name.

a unix-like "mv" command is virtually instantaneous, whereas a copy command slows down depending on your network and the size of the file.
 
Bhushan Bhawsar
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good one.
 
Maneesh Godbole
Bartender
Posts: 11445
18
Android Eclipse IDE Google Web Toolkit Java Mac Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
abhinas raj wrote:
here the use case is some one will copy the file manually in a location, now my application need to know that when that file copy has been completed.
1) checking the size of the every time file, and if its size is not changed after some time, then we will assume file is copied
2) checking the file modified time every time.
these two methods will not work as per our aspectations.

we need another solution for this.



Consider using the WatchService
https://docs.oracle.com/javase/tutorial/essential/io/notification.html
Since it is a part of the 'standard Java', it should work on all platforms.
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
abhinas raj wrote:here the use case is some one will copy the file manually in a location, now my application need to know that when that file copy has been completed.
1) checking the size of the every time file, and if its size is not changed after some time, then we will assume file is copied
2) checking the file modified time every time.
these two methods will not work as per our aspectations.

Actually, they probably won't. The "size" of a file that is being updated is generally spurious, and its accuracy will likely vary wildly by OS. Same with modification time, which is even worse because it may give you a "false positive". And neither technique actually gives you any assurance that the copy was successful.

we need another solution for this.

I'd read Fred's last post (copy to temp file, then move) because it's by far the easiest method to use if you trust your 'copy' utility. Indeed, I think it's the standard for things like FTP (but I could be wrong).

If you can't trust your copy utility, then the simplest thing to do is to have it first send a "digest" (eg, an MD5 checksum) of the file in question, and then do the copy (or copy and move). Your "receiver" then:
(a) Checks if the file has arrived.
(b) Validates it against the digest.
I suggest MD5 because it's pretty robust, and there are almost certainly Java library classes for reading .md5 files and doing the check.

HIH

Winston
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Completed" means different things. To Java, "completed" means that data has been passed on to the filesystem. On Linux, filesystem operations occur on buffers that are (eventually, one hopes) flushed out to disk. Even the disk doesn't provide total assurance, since a disk transfer usually writes to the disk's on-board cache and only later does the cache get physically recorded.

The linux sync command can help somewhat, because it won't return until the filesystem has been synced (flushed to disk), but like I said, that doesn't necessarily account for what happens inside the disk. Modern Linux filesystem environments are pretty sophisticated, so I'd recommend a good long browse of google and a stop or two at tldp.org.

For most of us, assuming reliable power and devices, we can get by on Java's innate behavior. For more sophisticated stuff (such as device or filesystem benchmarking) it can get a little more complex.

Incidentally, Windows does file locking based on the filename path. Linux does file locking based on the actual file inode. That means that if you rename a file in Linux, the file remains locked, just under a new name, but in Windows, you have to unlock the name itself. That's one reason why so many Windows updates require reboots - the standard mechanism doesn't allow creating a new version of the file while the old version is locked.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!