Closed DmitryLitvintsev closed 1 year ago
The dCache code has
public MkDirRequest(ByteBuf buffer) {
super(buffer, 3008);
this.options = (short)buffer.getByte(4);
this.mode = buffer.getUnsignedShort(18);
}
public short getOptions() {
return this.options;
}
public boolean shouldMkPath() {
return (this.getOptions() & 1) == 1;
}
Not sure what it really expects as the option ....
but it looks like this
public void createDirectory(FsPath path,
boolean createParents,
Subject subject,
Restriction restriction) throws CacheException {
PnfsHandler pnfsHandler = new PnfsHandler(_pnfs, subject, restriction);
if (!isWriteAllowed(path)) {
throw new PermissionDeniedCacheException("Write permission denied");
}
if (createParents) {
pnfsHandler.createDirectories(path);
} else {
pnfsHandler.createPnfsDirectory(path.toString());
}
}
will make the parents, but not behave exactly like -p
...
So I guess all it will take is to check for file existence under the if (createParents) ...
I think all it needs a check for file exists error and ignore it for "-p" option else continue like it was before.
how is the "-p" option is passed by xrood - that is the most difficult part.
I haven't checked yet, but I believe the client parses the '-p' into an integer option (evidently 1).
This is more a question I think of conformity inside dCache. Should probably see what the behavior of the xrootd server is to compare.
PNFS:
[root@fndcaitb2 litvinse]# mkdir -p a/b/c
[root@fndcaitb2 litvinse]# mkdir -p a/b/c
[root@fndcaitb2 litvinse]# echo $?
0
https://xrootd.slac.stanford.edu/doc/dev56/XRdv520.htm#_Toc138799706
kXR_mkdir | | 3008 | Create a directory
-- | -- | -- | --
| mode | |
| kXR_ur | 0x01 00 | Owner readable
| kXR_uw | 0x00 80 | Owner writable
| kXR_ux | 0x00 40 | Owner searchable (directories)
| kXR_gr | 0x00 20 | Group readable
| kXR_gw | 0x00 10 | Group writable
| kXR_gx | 0x00 08 | Group searchable (directories)
| kXR_or | 0x00 04 | Other readable
| kXR_ow | 0x00 02 | Other writable (not allowed)
| kXR_ox | 0x00 01 | Other searchable (directories)
| options | |
| kXR_mkdirpath | 0x01 | Create missing directories in path
options to apply when path is created. The options are an “or’d” combination of the following values:
kXR_mkdirpath - create directory path if it does not already exist
xrdfs man says
mkdir [-p] [-m<user><group><other>] <dirname>
Creates a directory/tree of directories.
-p create the entire directory tree recursively
-m<user><group><other> permissions for newly created directories
So my assumption is that the xrdfs parser turns -p
into 0x01
PNFS:
[root@fndcaitb2 litvinse]# mkdir -p a/b/c [root@fndcaitb2 litvinse]# mkdir -p a/b/c [root@fndcaitb2 litvinse]# echo $? 0
What I meant was conformity (with the protocol) in the dCache implementation of XrootD, not NFS or in general ... Sorry for the ambiguity
My angle with PNFS is this. I checked that PNFS follows POSIX. Xrdfs tries to follow POSIX. Looks like EOS follows (EOS uses xrootd under the covers). So it makes sense to have this feature. That's all.
The analogy with POSIX is incorrect. Thw mkdir function always returns error if directory exist. It's client application (mkdir command) that ignores it and keep going.
@kofemann so is that an objection to doing what @DmitryLitvintsev , or just an observation about the POSIX standard?
Personally, I think that if the vanilla xroot server behaves this way, then xroot in dCache should as well. (Obviously it is not the xrdfs client that is ignoring the failure, because it fails with dCache but not with EOS).
Vanilla server:
[arossi@fndcatemp1 ~]$ xrdfs5x root://fndcatemp1.fnal.gov:1095 "mkdir -p /data/xrootdfs/arossi/a/b/c"
[arossi@fndcatemp1 ~]$ ls -l /data/xrootdfs/arossi/a/b
total 4
drwxr-x--- 2 arossi dcache 4096 Jul 27 07:40 c
[arossi@fndcatemp1 ~]$ xrdfs5x root://fndcatemp1.fnal.gov:1095 "mkdir -p /data/xrootdfs/arossi/a/b/c"
[arossi@fndcatemp1 ~]$ ls -l /data/xrootdfs/arossi/a/b
total 4
drwxr-x--- 2 arossi dcache 4096 Jul 27 07:40 c
The analogy with POSIX is incorrect. Thw mkdir function always returns error if directory exist. It's client application (mkdir command) that ignores it and keep going.
yeah, I suspected that. But.... it does not matter a user :)
@alrossi No, we should the expected behavior (EOS?). My comment was more that the mkdir
behavior is not implemented in dCache.
@kofemann that's what I figured. So I'll go ahead and create a patch.
From slack chat
On Linux:
that is "-p" option does not give file exist error