XFS dmapi: dm_path_to_handle fails if the path is a directory

XFS dmapi: dm_path_to_handle fails if the path is a directory

[John Groves]

I'm running up against a difficult situation because dm_path_to_handle 
does not return a handle, if the path is to a directory.  Is this a 
known issue, or perhaps fixed in a recent version?  Or is there another 
way get the handle of a directory by path?  When any file type is 
renamed, I (for various reasons) *must* know not just the old & new 
parent handles, but also the handle of the renamed thingy.  If the 
thingy is a directory, I'm stuck at the moment.

My test system has dmapi 2.2.1-5, which I don't think is current, but I 
can't seem to get access to the oss.sgi.com server to check.

Any advice or info appreciated.  I'm willing to try and submit a patch, 
but I'd appreciate first knowing whether there was a specific reason or 
problem that led to the current behavior.

Thanks,
John Groves

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[Vlad Apostolov]

John Groves wrote:
> I'm running up against a difficult situation because dm_path_to_handle 
> does not return a handle, if the path is to a directory.  Is this a 
> known issue, or perhaps fixed in a recent version?  Or is there 
> another way get the handle of a directory by path?  When any file type 
> is renamed, I (for various reasons) *must* know not just the old & new 
> parent handles, but also the handle of the renamed thingy.  If the 
> thingy is a directory, I'm stuck at the moment.
>
> My test system has dmapi 2.2.1-5, which I don't think is current, but 
> I can't seem to get access to the oss.sgi.com server to check.
>
> Any advice or info appreciated.  I'm willing to try and submit a 
> patch, but I'd appreciate first knowing whether there was a specific 
> reason or problem that led to the current behavior.
>
> Thanks,
> John Groves
>
Hi John,

If your path is longer than 2000 characters dm_path_to_handle used to fail.
This bug was fixed in August 2006. Please update your tree from here:

http://oss.sgi.com/projects/xfs/download.html

Regards,
Vlad

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[Vlad Apostolov]

Vlad Apostolov wrote:
> John Groves wrote:
>> I'm running up against a difficult situation because 
>> dm_path_to_handle does not return a handle, if the path is to a 
>> directory.  Is this a known issue, or perhaps fixed in a recent 
>> version?  Or is there another way get the handle of a directory by 
>> path?  When any file type is renamed, I (for various reasons) *must* 
>> know not just the old & new parent handles, but also the handle of 
>> the renamed thingy.  If the thingy is a directory, I'm stuck at the 
>> moment.
>>
>> My test system has dmapi 2.2.1-5, which I don't think is current, but 
>> I can't seem to get access to the oss.sgi.com server to check.
>>
>> Any advice or info appreciated.  I'm willing to try and submit a 
>> patch, but I'd appreciate first knowing whether there was a specific 
>> reason or problem that led to the current behavior.
>>
>> Thanks,
>> John Groves
>>
> Hi John,
>
> If your path is longer than 2000 characters dm_path_to_handle used to 
> fail.
> This bug was fixed in August 2006. Please update your tree from here:
>
> http://oss.sgi.com/projects/xfs/download.html
>
> Regards,
> Vlad
>
You could also see an example of how to use dm_path_to_handle() in

xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle.c

Here is the output for a regular file and a directory:

vapo@emu ~/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd> ls -al /mnt/scratch1
total 8
drwxrwxrwx 4 root root    46 2006-11-01 12:04 .
drwxr-xr-x 8 root root    89 2006-10-30 14:23 ..
drwxr-xr-x 7 root root  4096 2006-10-26 10:56 dmapi
drwxr-xr-x 8 root root  4096 2006-10-26 10:56 dmapi_test
-rw-r--r-- 1 vapo cdrom    0 2006-11-01 12:04 file
vapo@emu ~/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd> sudo  
./path_to_handle /mnt/scratch1/file
5d1111a90e4800000e000000710100009600000000000000
vapo@emu ~/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd> sudo  
./path_to_handle /mnt/scratch1/dmapi
5d1111a90e4800000e0000006e0000008300000000000000
vapo@emu ~/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd>

Regards,
Vlad

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[John Groves]

Thanks for your replies, Vlad, although I don't find anything so far 
that helps with my problem (my paths are not long, and my calls to 
dm_path_to_handle have been running in production environments for a 
couple of years).  As far as I can see, dm_path_to_handle does not work 
on a directory (?), although it works perfectly on a file.  I will try 
to dig deeper into this over the next few days, but here is a somewhat 
clearer explanation of the behavior I am seeing.

I have updated to the latest kernel from SGI's CVS server, but the 
problem is still there.  I am tracing through kernel code, and will be 
happy to pull together some test code that demonstrates the problem, or 
to post a patch if I figure it out, but this will take a few days.

The sequence in which I find this problem is:

    1. Receive a pre-rename event
    2. Use the first handle parameter to resolve the pre-rename parent 
directory path (not via dm_handle_to_path -- I had to roll my own 
mechanisms for turning handles into paths).
    3. Concatenate the first name parameter to the first parent 
directory path, to get the relative path from mount point to actual file 
being renamed.
    4. Call dm_path_to_handle on that path, hoping to get the handle of 
the file-being-renamed.

If the renamed-thing is a file, this works.  If it's a directory, 
dm_path_to_handle fails.

With my dmapi event handler installed and running, I can reproduce it by 
doing the following in the root directory of the filesystem:

mkdir -p x/y/z
mv x/y x/w

In the pre-rename event, prior to responding to the event, my handler 
correctly determines that x/y is being renamed to x/w, but 
dm_path_to_handle does not return the handle of x/y.  My post-rename 
event handler also correctly resolves the paths, but dm_path_to_handle 
does not return the handle of x/w.

If x/y is a file (rather than a directory) it all works properly.

Let me know if you can think of anything specific I should look at, or 
of a different way of getting the handle of the renamed thingy.

Thanks,
John Groves

Vlad Apostolov wrote:
> John Groves wrote:
> 
>> I'm running up against a difficult situation because dm_path_to_handle 
>> does not return a handle, if the path is to a directory.  Is this a 
>> known issue, or perhaps fixed in a recent version?  Or is there 
>> another way get the handle of a directory by path?  When any file type 
>> is renamed, I (for various reasons) *must* know not just the old & new 
>> parent handles, but also the handle of the renamed thingy.  If the 
>> thingy is a directory, I'm stuck at the moment.
>>
>> My test system has dmapi 2.2.1-5, which I don't think is current, but 
>> I can't seem to get access to the oss.sgi.com server to check.
>>
>> Any advice or info appreciated.  I'm willing to try and submit a 
>> patch, but I'd appreciate first knowing whether there was a specific 
>> reason or problem that led to the current behavior.
>>
>> Thanks,
>> John Groves
>>
> Hi John,
> 
> If your path is longer than 2000 characters dm_path_to_handle used to fail.
> This bug was fixed in August 2006. Please update your tree from here:
> 
> http://oss.sgi.com/projects/xfs/download.html
> 
> Regards,
> Vlad
> 
> 
> 
> 

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[Vlad Apostolov]

John Groves wrote:
> Thanks for your replies, Vlad, although I don't find anything so far 
> that helps with my problem (my paths are not long, and my calls to 
> dm_path_to_handle have been running in production environments for a 
> couple of years).  As far as I can see, dm_path_to_handle does not 
> work on a directory (?), although it works perfectly on a file.  I 
> will try to dig deeper into this over the next few days, but here is a 
> somewhat clearer explanation of the behavior I am seeing.
>
> I have updated to the latest kernel from SGI's CVS server, but the 
> problem is still there.  I am tracing through kernel code, and will be 
> happy to pull together some test code that demonstrates the problem, 
> or to post a patch if I figure it out, but this will take a few days.
>
> The sequence in which I find this problem is:
>
>    1. Receive a pre-rename event
>    2. Use the first handle parameter to resolve the pre-rename parent 
> directory path (not via dm_handle_to_path -- I had to roll my own 
> mechanisms for turning handles into paths).
>    3. Concatenate the first name parameter to the first parent 
> directory path, to get the relative path from mount point to actual 
> file being renamed.
>    4. Call dm_path_to_handle on that path, hoping to get the handle of 
> the file-being-renamed.
>
> If the renamed-thing is a file, this works.  If it's a directory, 
> dm_path_to_handle fails.
>
> With my dmapi event handler installed and running, I can reproduce it 
> by doing the following in the root directory of the filesystem:
>
> mkdir -p x/y/z
> mv x/y x/w
>
> In the pre-rename event, prior to responding to the event, my handler 
> correctly determines that x/y is being renamed to x/w, but 
> dm_path_to_handle does not return the handle of x/y.  My post-rename 
> event handler also correctly resolves the paths, but dm_path_to_handle 
> does not return the handle of x/w.
>
> If x/y is a file (rather than a directory) it all works properly.
>
> Let me know if you can think of anything specific I should look at, or 
> of a different way of getting the handle of the renamed thingy.
Hi John,

I did try this on my dmapi filesystem:

emu:/mnt/scratch1/dmapi_test # mkdir -p x/y/z
emu:/mnt/scratch1/dmapi_test # 
/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/y
5d1111a90e4800000e00000003000000d903400000000000
emu:/mnt/scratch1/dmapi_test # mv x/y x/w
emu:/mnt/scratch1/dmapi_test # 
/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/w
5d1111a90e4800000e00000003000000d903400000000000
emu:/mnt/scratch1/dmapi_test #

I also tried path_to_handle with relative path to a directory it worked 
fine too. When you say
dm_path_to_handle fails, what is the error returned?

Regards,
Vlad

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[John Groves]

Vlad Apostolov wrote:

> Hi John,
>
> I did try this on my dmapi filesystem:
>
> emu:/mnt/scratch1/dmapi_test # mkdir -p x/y/z
> emu:/mnt/scratch1/dmapi_test # 
> /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/y
> 5d1111a90e4800000e00000003000000d903400000000000
> emu:/mnt/scratch1/dmapi_test # mv x/y x/w
> emu:/mnt/scratch1/dmapi_test # 
> /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/w
> 5d1111a90e4800000e00000003000000d903400000000000
> emu:/mnt/scratch1/dmapi_test #
>
> I also tried path_to_handle with relative path to a directory it 
> worked fine too. When you say
> dm_path_to_handle fails, what is the error returned?
>
> Regards,
> Vlad
>

Vlad,

This was my bad -- I need to go back to programming school ;-).

The function in question was dealing in mount-point-relative paths, not 
full paths, and I didn't notice the distinction.  Passing a full path to 
dm_path_to_handle fixed it.  As for thinking it behaved differently for 
a directory than for a file -- I've been smoking a batch of bad crack 
;-).  Calling dm_path_to_handle also failed with relative paths to files 
-- I just didn't notice because it wasn't fatal on that code path.

Thanks for responding and looking into it, though.

Regards,
John

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[Vlad Apostolov]

John Groves wrote:
> Vlad Apostolov wrote:
>
>> Hi John,
>>
>> I did try this on my dmapi filesystem:
>>
>> emu:/mnt/scratch1/dmapi_test # mkdir -p x/y/z
>> emu:/mnt/scratch1/dmapi_test # 
>> /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle 
>> x/y
>> 5d1111a90e4800000e00000003000000d903400000000000
>> emu:/mnt/scratch1/dmapi_test # mv x/y x/w
>> emu:/mnt/scratch1/dmapi_test # 
>> /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle 
>> x/w
>> 5d1111a90e4800000e00000003000000d903400000000000
>> emu:/mnt/scratch1/dmapi_test #
>>
>> I also tried path_to_handle with relative path to a directory it 
>> worked fine too. When you say
>> dm_path_to_handle fails, what is the error returned?
>>
>> Regards,
>> Vlad
>>
>
> Vlad,
>
> This was my bad -- I need to go back to programming school ;-).
>
> The function in question was dealing in mount-point-relative paths, 
> not full paths, and I didn't notice the distinction.  Passing a full 
> path to dm_path_to_handle fixed it.  As for thinking it behaved 
> differently for a directory than for a file -- I've been smoking a 
> batch of bad crack ;-).  Calling dm_path_to_handle also failed with 
> relative paths to files -- I just didn't notice because it wasn't 
> fatal on that code path.
>
> Thanks for responding and looking into it, though.
>
> Regards,
> John
>
No problems John,

Just a note that dm_path_to_handle works fine with relative paths on my 
machine.

Regards,
Vlad

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[John Groves]

Vlad Apostolov wrote:

> Just a note that dm_path_to_handle works fine with relative paths on my 
> machine.

In your case, could it be applying the "current working directory" from 
the process context to resolve a full path?  Mine is a daemon, and the 
relative paths are not valid relative to the "cwd" in which the daemon 
was started.

...just a thought.  Otherwise, for the moment I may have to just accept 
it as weird...

Thanks again,
John

Re: XFS dmapi: dm_path_to_handle fails if the path is a directory

[Vlad Apostolov]

John Groves wrote:
>
>
> Vlad Apostolov wrote:
>
>> Just a note that dm_path_to_handle works fine with relative paths on 
>> my machine.
>
> In your case, could it be applying the "current working directory" 
> from the process context to resolve a full path?  Mine is a daemon, 
> and the relative paths are not valid relative to the "cwd" in which 
> the daemon was started.
>
> ...just a thought.  Otherwise, for the moment I may have to just 
> accept it as weird...
>
> Thanks again,
> John
I am using

xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle

and the relative path passed as an argument is directly given to 
dm_path_to_handle().
The current working directory
I can't really explain why it doesn't work in your case. Here is an 
example of a directory
path to handle I get:

emu:/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd # 
./path_to_handle /mnt/scratch1/dmapi
5d1111a90e4800000e0000006e0000008300000000000000
emu:/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd # 
./path_to_handle ../../../../../../../../../mnt/scratch1/dmapi
5d1111a90e4800000e0000006e0000008300000000000000
emu:/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd # cd /
emu:/ # 
/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle 
../../../../../../../../../mnt/scratch1/dmapi
5d1111a90e4800000e0000006e0000008300000000000000

Regards,
Vlad