Re: [HTCondor-users] File transfers and symlinks along the path

[Jaime Frey <jfrey@xxxxxxxxxxx>]

> On May 2, 2023, at 4:08 AM, Steffen Grunewald <Steffen.Grunewald@xxxxxxxxxx> wrote:
> 
> On Mon, 2023-05-01 at 15:06:23 +0000, HTCondor Users Mailinglist wrote:
>> I donât know why HTCondor would add a bunch of â../â path elements. It generally leaves pathnames untouched, pastes the Iwd to the front of relative paths, or uses realpath() to get the canonicalized absolute path (again using Iwd for relative paths).
>> 
>> With jobs that have an Iwd that starts with â/.auto/home/â, what do the file transfer attributes look like (e.g. TransferInput)?
> 
> I wish I could have presented such a job not only from memory, but the affected user
> decided to remove the held jobs instead of leaving them for closer inspection.
> Whatever does the path modifications, it ends up with /.auto/home/........./home/.........
> which contains (contained, as we have modified our mount strategy in a hurry) a symlinked
> /home/ right in the middle, causing the file transfer to complain.

You can check to see if the affected jobs are still visible with condor_history.

> Since the underlying "problem" (our approach at auto-mounting) has been "resolved"
> only the question remains "why" - iow, the rationale behind symlinks being forbidden
> - as this may hit us in another place, too.


A symlink in the middle of a pathname should not be an issue. The thing our file transfer code explicitly rejects is when the last element of a file transfer pathname is a symlink which points to a directory.
So your example of /.auto/home/user/foo/bar/baz/../../../../../../home/user/foo/bar/baz should be fine as long as baz isnât a symlink to a directory.

 - Jaime