Aha, now I understand what you mean. The one corner case to consider is if
the program opens the file "A.txt" twice. Once using the relative path
"A.txt" and once using the absolute path "/tmp/xyz/A.txt".
As you have guessed, currently, DMTCP looks up /proc/self/fd to find the
filepath and its not possible to find if the file was opened using relative
path or absolute path at that moment. However, we can always do some more
work in open() wrapper and mark the file descriptor as such, but the
problem lies in the fact that one then needs to keep track of dup() etc
calls that may change the file descriptor.
As far as I know, there is no way to query the kernel/procfs to find out
the way the file was opened :-(, do you have any ideas?
Kapil
On Thu, Sep 27, 2012 at 12:12 PM, Louie, Joshua D
<[email protected]>wrote:
> Hi Kapil,****
>
> ****
>
> It looks to me like you reversed the priority of checking the original
> location vs the relative location, which isn’t exactly what I was wondering
> about.****
>
> I think the original behavior is closer to desired. So let me explain
> through an example what I’m seeing/thinking.****
>
> ** **
>
> 1. Original DMTCP behavior****
>
> Program running and checkpointed in /tmp/xyz. Opens 3 files “A.txt”,
> “/tmp/xyz/B.txt”, and “/tmp/other/C.txt”.****
>
> From the program’s perspective****
>
> A.txt is relative****
>
> B.txt and C.txt are absolute paths****
>
> From DMTCP’s perspective,****
>
> A.txt and B.txt are relative (because they’re located in the original
> directory or subdir)****
>
> C.txt is an absolute path (not in original directory or subdir)****
>
> During restart (assume we’ve moved checkpoint to /tmp/abc),****
>
> Check for A.txt and B.txt in relation to current working
> directory (/tmp/abc).****
>
> If they are not there, check for them in original path (/tmp/xyz)****
>
> Check for C.txt in absolute path (/tmp/other)****
>
> ** **
>
> From this, you can see that the program’s perspective is not the same as
> DMTCP’s perspective.****
>
> When I restart in some other directory, I’d expect us to look for A.txt in
> the current working directory,****
>
> and B.txt and C.txt would be grabbed from the absolute paths they were
> given.****
>
> ** **
>
> My question is, is the reason that the program’s perspective and DMTCP’s
> perspective different due****
>
> to the manner by which DMTCP saves the file pointers? My guess would be
> that DMTCP uses the****
>
> file descriptor table, which has all the paths as fully resolved and thus
> DMTCP has to guess as what****
>
> was given as a “relative” path when the file pointer is created.****
>
> ** **
>
> If that’s the case, that’s fine, I just need to keep that in mind as I
> tackle different scenarios. Thanks.****
>
> ****
>
> Joshua Louie****
>
> ** **
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Dmtcp-forum mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
