[Buildroot] Per-package download folders and Git caching

[Arnout Vandecappelle]

On 03-04-18 22:48, Yann E. MORIN wrote:
> Arnout, All,
> 
> On 2018-04-03 22:44 +0200, Arnout Vandecappelle spake thusly:
>> On 03-04-18 19:49, Yann E. MORIN wrote:
>>> Peter, All,
>>>
>>> On 2018-04-03 18:49 +0200, Peter Korsgaard spake thusly:
>>>>>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
>>>>  > Should we do a cp if ln fails, then?
>>>> That sounds like a sensible fallback, yes.
>>>
>>> I was about to do so, but then we're back to a situation where we have
>>> to guarantee the atomicity.
>>>
>>> This is currently possible, because the dl-wrapper now runs under flock.
>>> But we are going to optimise the locking with a more fine-grained
>>> solution soonish.
>>>
>>> To be noted: the current code is not atomic-safe either, because we do
>>> have a TOCTTOU situation...
>>>
>>> So, we'll have to again play tricks with atomicity...
>>>
>>> We can't use flock again, because the destination directory is already
>>> locked, and there is not destination file to lock to start with...
>>>
>>> So, maybe the full solution will in fact to really implement the more
>>> fine-grained solution... I'll see to it.
>>
>>  Note that for the specific case I mentioned (hardlinks may not work over samba
>> or VM shares), flock will fail as well...
> 
> Wait... So you're saying that we borked a working situation for a certain
> class of users, now? Damn... :-/
> 
> And why would flock fail on those (curious)?

 As I remember, flock(2) doesn't work on Samba (or NFS for that matter). I
couldn't find any real reference for that, however, just some unanswered SO
question [1]. And since flock(1) uses flock(2)...

 That said, Samba _does_ support fcntl(2), so I don't see why it wouldn't
support flock(2)...

 Regards,
 Arnout

[1]
https://stackoverflow.com/questions/47632116/does-cifs-byte-range-locking-work-across-multiple-linux-client-nodes-with-window

>>  Maybe we should just wait until someone complains so they can test whatever
>> solution we come up with.
> 
> In the end, yes, probably...
> 
> Regards,
> Yann E. MORIN.
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF