Forum > General

Copy a Linux file in use?

<< < (2/4) > >>

Thaddy:

--- Quote from: KarenT on November 15, 2018, 02:54:36 pm ---
--- Quote from: lucamar on November 14, 2018, 10:19:15 pm ---If it's not doing that then something else is (very?) wrong.

--- End quote ---

Thanks, I had already tried all of those things and it was still doing the wandering off. The program would go dark and stay that way.

I was able to trace another level deeper and it is getting to the SystUtils OpenFile call and not coming back but have been unable to get any deeper into it than that.

I also tried changing the FileUtil.inc Permissions to allow me to change the "OpenFile" flags to "DenyNone" but still it crashes. I am with you, something is VERY wrong.

For now I will hard program out the Veracrypt folder. But, methinks a bug is wallowing in there somewhere.

--- End quote ---
No.
methinks it is OK. Did you try my suggestion - from the other thread - to use a file stream? That gives you more control.

KarenT:
Thanks Thaddy, but let's not be hasty. :)

As mentioned, I tried changing the calls within FileUtil.inc and still the same. That call allows setting the "share" flags etc. And, I had tried all "or" combinations of **all* available Flags. Always the same crash.


--- Code: ---    SrcHandle := LazFileUtils.FileOpenUTF8(SrcFilename, fmOpenRead or fmShareDenyWrite);

--- End code ---

Also I copied the program to an i5 Surface Pro running 16.04 and same thing with two other files. I am not able to step through iton the Surface Pro as Lazarus is not installed.

lucamar:

--- Quote from: KarenT on November 15, 2018, 04:08:40 pm ---As mentioned, I tried changing the calls within FileUtil.inc and still the same. That call allows setting the "share" flags etc. And, I had tried all "or" combinations of **all* available Flags. Always the same crash.


--- Code: ---    SrcHandle := LazFileUtils.FileOpenUTF8(SrcFilename, fmOpenRead or fmShareDenyWrite);

--- End code ---

Also I copied the program to an i5 Surface Pro running 16.04 and same thing with two other files. I am not able to step through iton the Surface Pro as Lazarus is not installed.

--- End quote ---

Take into account that if other processes have completely locked those files your program won't be able to open them no matter what flags you use, which is as it should. The problem, really, seems to be that in those conditions the (ultimate) call to fpOpen() locks your application, as if it were waiting for the file to become unlocked. I haven't been able to dive deeper (lack of time) but something about this should be mentioned in either the kernel or the C library documentation.

All in all, Thaddy's sugestion is sound: try to implement it yourself, which will make it more easy to debug.

KarenT:

--- Quote from: lucamar on November 15, 2018, 04:38:14 pm ---All in all, Thaddy's sugestion is sound: try to implement it yourself, which will make it more easy to debug.

--- End quote ---

Thanks, the "waiting to open" makes sense as it just hangs. When debugging I get to the SysUtils.OpenFile line and the visual line selection goes away.

But, writing my own copy-file function is way out of my league, especially with Linux.

lucamar:

--- Quote from: KarenT on November 15, 2018, 05:00:55 pm ---But, writing my own copy-file function is way out of my league, especially with Linux.

--- End quote ---

There's very little "magic" in a CopyFile function; a very basic algorithm is something like:

--- Code: ---if not OpenFile(Source) then
  return False or raise an exception
else begin
  if not OpenFile(Destination) then
    return False or raise an exception
  else
    while not Eof(Source) do begin
      Read(Source, Buffer)
      Write(Destination, Buffer)
    end
  CloseFile(Source)
  CloseFile(Destination)
end
return True
--- End code ---

Add in some error detection and recovery--and  a few bells&whistles--and you're done :)

It can be made shorter using streams, though then the "complexities" go into the streams implementation.

ETA I may be wrong but I think the original problem is due to the implementation of sysutils.FileOpen. At its heart there is this:


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---  repeat    FileOpen:=fpOpen (pointer(SystemFileName),LinuxFlags);  until (FileOpen<>-1) or (fpgeterrno<>ESysEINTR); 
Under certain conditions that loop will run forever. First, because the call is blocking (no O_NonBlock in LinuxFlags) and then because it doesn't allow for fpOpen to fail (which would return -1). My main doubt is about when the error will (or won't) be ESysEINTR.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version