in reply to Random script crashes related to File::Copy

roboticus, no, the "Invalid cross-device link" error is caught by File::Copy::move() and causes it to try to copy the file and then unlink.

runrig, no, "trying to delete the file while it is still being written to" is not in evidence in the traces provided. The trace shows the destination being unlinked (despite it never having been created) after the source could not be opened.

As the original poster correctly noted, the problem is: 

open("/mnt­/xfer/3165­0_WRETCHED Radio 04-25_DIST­.wav", O_RDONLY|O­_L
+ARGEFILE­) = -1 ETXTBSY (Text file busy

[download]

So the addition of $! will likely add "Text file busy" to the output.

I've only ever seen that error when trying to delete an executable image when it was in use. On a good Unix platform, "man 2 open" will actually note more details about what "Text file busy" really means in the case of open() failing.

Indeed, open(2) says:

ETXTBSY
The file is a pure procedure (shared text) file that is being executed and the open() system call requests write access.

which doesn't match the name *.wav nor O_RDONLY so the original poster might want to check "man 2 open" on his particular operating system (and hope that it has "good" man pages in this respect).

- tye        

Replies are listed 'Best First'.
Re^2: Random script crashes related to File::Copy (care)
by michael.barnes (Novice) on Apr 29, 2009 at 16:50 UTC

    Let me add a little more information. This script transfers several dozen files per day. The files are either plain text, mp3 or wav audio files. It may run flawlessly for several days, then it might crash 5 or 6 times in one day.

    If it crashes during the transfer attempt of a file, when restarted, it transfers the file without problem.

    Hence, I believe the problem is somehow timing related rather than the actual command structure. If the problem was really related to "Invalid cross-device link" errors or the like, would that not then cause the script to crash every time? I would think that type of error is more a result of an underlying problem.



    BTW, this is my first post on Perl Monks. I am truly impressed by the speed and quality of responses. Thank you all very much. I am anticipating a solution soon, thanks to your collective knowledge and kindness.



    Michael
[reply]

      How do you know that the file has finished being written before you start copying it? In such situations, I usually recommend that you have a standardized naming convention for "still writing to the file" like "*.tmp" and then have whatever process is writing the file rename it to remove the ".tmp" after it is finished writing it.

      If after you have (already?) solved the above concern, the "text file busy" problem (besides causing me to research what that error really means which might even lead me to reading OS source code) would lead me to detecting move() failing and leaving $! set to ETXTBUSY (from Errno) and then just sleeping and retrying a couple of times.

      - tye        

[reply]

      Hence, I believe the problem is somehow timing related rather than the actual command structure. If the problem was really related to "Invalid cross-device link" errors or the like, would that not then cause the script to crash every time

      Not all. After all, "Text file busy" means *something else* (another handle? another process?) is keeping the file "busy" (mmapped?).

[reply]

        Your response appears to be a result of a faulty parsing of English. "If X, then would crash every time" vs "Not every time, because Y could be timing related". While "X" is "not Y".

        - tye        

[reply]

In Section Seekers of Perl Wisdom