Return to Question

minor edits

Source Link

edit approved Mar 20, 2017 at 14:56

I am working on a CI runner in gitlabGitLab which is supposed to transfer changed files via FTP to a development environment.

lftp seemed to be a good solution for doing so as it´sit's easy to use and not overly complicated.

I am using this to transfer files:
lftp -c "set ftp:ssl-allow no; open -u $USERNAME_DEV,$PASSWORD_DEV $HOST_DEV; mirror -Rvpn -O $PATH_DEV --ignore-time --parallel=10 --exclude-glob .git* --exclude .git/"

lftp -c "set ftp:ssl-allow no; open -u $USERNAME_DEV,$PASSWORD_DEV $HOST_DEV; mirror -Rvpn -O $PATH_DEV --ignore-time --parallel=10 --exclude-glob .git* --exclude .git/"

The problematic part is the -Rvpn parameter set, specifically the -n. This is supposed to mirror only newer files which will most probably work by checking file change times.

Now my repository uses the correct time but my server is one hour in advance (GMT+2 instead of +1) which will lead to a false when checking for newer files.

I could remove the -n but then the whole repository would be cloned, not only the changed (and therefore newer) files.

Is there any way to define a time offset for lftp, so it adds +1 hour to the file change date or something similar? I checked the manual but did not find anything like that.

I am working on a CI runner in gitlab which is supposed to transfer changed files via FTP to a development environment.

lftp seemed to be a good solution for doing so as it´s easy to use and not overly complicated.

The problematic part is the -Rvpn parameter set, specifically the -n. This is supposed to mirror only newer files which will most probably work by checking file change times.

Now my repository uses the correct time but my server is one hour in advance (GMT+2 instead of +1) which will lead to a false when checking for newer files.

I could remove the -n but then the whole repository would be cloned, not only the changed (and therefore newer) files.

Is there any way to define a time offset for lftp, so it adds +1 hour to the file change date or something similar? I checked the manual but did not find anything like that.

I am working on a CI runner in GitLab which is supposed to transfer changed files via FTP to a development environment.

lftp seemed to be a good solution for doing so as it's easy to use and not overly complicated.

I am using this to transfer files:

lftp -c "set ftp:ssl-allow no; open -u $USERNAME_DEV,$PASSWORD_DEV $HOST_DEV; mirror -Rvpn -O $PATH_DEV --ignore-time --parallel=10 --exclude-glob .git* --exclude .git/"

The problematic part is the -Rvpn parameter set, specifically the -n. This is supposed to mirror only newer files which will most probably work by checking file change times.

Now my repository uses the correct time but my server is one hour in advance (GMT+2 instead of +1) which will lead to a false when checking for newer files.

I could remove the -n but then the whole repository would be cloned, not only the changed (and therefore newer) files.

Is there any way to define a time offset for lftp, so it adds +1 hour to the file change date or something similar? I checked the manual but did not find anything like that.

Source Link

asked Mar 16, 2017 at 9:35

flomei

Add time offset for mirroring via lftp

I am working on a CI runner in gitlab which is supposed to transfer changed files via FTP to a development environment.

lftp seemed to be a good solution for doing so as it´s easy to use and not overly complicated.

The problematic part is the -Rvpn parameter set, specifically the -n. This is supposed to mirror only newer files which will most probably work by checking file change times.

Now my repository uses the correct time but my server is one hour in advance (GMT+2 instead of +1) which will lead to a false when checking for newer files.

I could remove the -n but then the whole repository would be cloned, not only the changed (and therefore newer) files.

Is there any way to define a time offset for lftp, so it adds +1 hour to the file change date or something similar? I checked the manual but did not find anything like that.