Re: [PATCHv2 5/5] fast-import: Fix minor data-loss issue with directories becoming symlinks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 6, 2010 at 1:34 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
> newren@xxxxxxxxx wrote:
>> From: Elijah Newren <newren@xxxxxxxxx>
>>
>> When fast-export runs across a directory changing to a symlink, it will
>> output the changes in the form
>>   M 120000 :239821 dir-changing-to-symlink
>>   D dir-changing-to-symlink/filename1
>> When fast-import sees the first line, it deletes the directory named
>> dir-changing-to-symlink (and any files below it) and creates a symlink in
>> its place.  When fast-import came across the second line, it was previously
>> trying to remove the file and relevant leading directories in
>> tree_content_remove(), and as a side effect it would delete the symlink
>> that was just created.  This resulted in the symlink silently missing from
>> the resulting repository.
>
> Ugh.
>
> I'm not against making the input parser more robust, but this is
> a violation of the stream format from fast-export.  The stream is
> incremental, a command like 'M' takes place immediately.  It is
> wrong for a frontend to output 'M foo', then 'D foo/bar'.
>
> IMHO, if fast-export is doing what you say above, the bug lies in
> fast-export, and therefore the fix should too.

Okay, I'll fix up fast-export.  Do you want me to drop this
fast-import patch, or does it still make sense as an extra robustness
check?

Elijah
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]