Symlinks not handled properly

[sfayer]

I have a symlink to a dir, it appears as a dir in the listing and I can't delete it (because gridftp rmdir says it isn't a directory). Symlinks should appear as links, so I'm not quite sure if it's the listing process or gridftp that's returning the wrong information?

[alexanderrichards]

From the web app end I can make them appear as links. Can @martynia check what the gfal scripts report. I'm pretty sure that they just give the status code which I am interpreting using stat.isdir. in this case can easily also check for link. If @martynia provides the correct tool for unlinking then I can use it. Do you see the same problem for file symlinks?

[sfayer]

Symlinks to files display as if they are just a normal file (with all the properties of the target)... Deletion of these works correctly.
I can see from the log that the returned listing is wrong...

[alexanderrichards]

Returned listing from worker to workqueue is wrong? And wrong how?

…

________________________________ From: sfayer <notifications@github.com> Sent: 26 June 2018 12:34:18 To: ic-hep/pdm Cc: Richards, Alexander J; Assign Subject: Re: [ic-hep/pdm] Symlinks not handled properly (#289) Symlinks to files display as if they are just a normal file (with all the properties of the target)... Deletion of these works correctly. I can see from the log that the returned listing is wrong... — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#289 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEeEXkCvjqotoMbnVA6cEXKbShmcKwl2ks5uAhw6gaJpZM4U3tFY>.

[sfayer]

Yes, but the listing returned from the gfal2_ls.py script is also wrong... It's doing the equivalent of stat rather than lstat, so symlinks are never visible. I'm starting to think it may be a bug in the gfal2 readdir implementation (or even gridftpd?), we'll have to do some specific tests to track it down...

[sfayer]

Well, it appears there is no workaround for this for now: Symlinks just have the type of the target in the listing. There is an extra parameter set in the listing (UNIX.slink), but I don't know if that's visible through gfal (I suspect not).

So, there are two tasks for Janusz:

1. Check if there is any way to get the slink field in the listing.
2. If not, modify the remove directory code to do an rm (unlink) before the rmdir (so symlinks are correctly deleted). If the rm succeeds, skip the rmdir, otherwise return the result from rmdir as the overall status.