From kfm-devel Sat Sep 21 13:47:54 2013 From: Mark Date: Sat, 21 Sep 2013 13:47:54 +0000 To: kfm-devel Subject: Re: UDSEntry compression ideas Message-Id: X-MARC-Message: https://marc.info/?l=kfm-devel&m=137977131111880 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--001a11c3ec70dee52e04e6e509c0" --001a11c3ec70dee52e04e6e509c0 Content-Type: text/plain; charset=ISO-8859-1 compile and run tested on frameworks. Also OK. I actually had one symlinked file (kdesrc-build) which still shows up as that dummy symlink which is as expected if i follow the code. On Sat, Sep 21, 2013 at 3:45 PM, Mark wrote: > On Sat, Sep 21, 2013 at 10:59 AM, David Faure wrote: > >> On Thursday 19 September 2013 23:13:04 Mark wrote: >> > If i set details to 0 i'm welcomed by a "UDSEntry::UDS_LINK_DEST" that >> > always seems to be: "Dummy Link Target". >> > When i don't set details (which means details is 2) then i don't have a >> > "UDSEntry::UDS_LINK_DEST" at all. That leads me to think that this >> > UDS_LINK_DEST might not be needed. Can i safely remove the >> > "UDSEntry::UDS_LINK_DEST" from the details == 0 code path? >> > Patch is here: http://paste.kde.org/pad68d0af/ >> >> That's not a fix, that's removing a feature instead of fixing it :-) >> >> UDS_LINK_DEST should only be set for symlinks. >> Are you saying that ep->d_type & DT_LNK is true for normal files too? >> Ah I see: >> This should say ep->d_type == DT_LNK, it's not a bitfield. >> (DT_LNK is 10, DT_REG is 8) >> Same for the other tests for d_type, they should all use == then. >> Can you test if that fixes what you're seeing, and commit (to 4.11) if so? >> Thanks. >> >> -- >> David Faure, faure@kde.org, http://www.davidfaure.fr >> Working on KDE, in particular KDE Frameworks 5 >> >> > I'm doing a bit of thread hijacking now (funny since i made it in the > first place ;p) > The patch: http://paste.kde.org/p2ece1fd8/ > Besides the line you said i also changed the line above. Hence asking for > a "OK" to commit. > Compile tested on 4.11 and works. The KIO Testcases run just fine as well > though i doubt they test for this case. > > Then a few questions for frameworks. How do i merge this change back in > frameworks? > > Note: i'm right now making a unittest for this specific case in > frameworks, not for 4.11. Just a general "udsentrytest" which should later > be extended to cover more of UDSEntry. > --001a11c3ec70dee52e04e6e509c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
compile and run tested on frameworks. Also OK. I actually = had one symlinked file (kdesrc-build) which still shows up as that dummy sy= mlink which is as expected if i follow the code.


On Sat, Sep 21, 2013 at 3:45 PM, Mark <= markg85@gmail.com> wrote:
On Sat, Sep 21, 2013 at 10:59 AM, D= avid Faure <faure@kde.org> wrote:
=
On Thursday 19 September 2013 23:13:04 Mark wrote:
> If i set details to 0 i'm welcomed by a "UDSEntry::UDS_LINK_D= EST" that
> always seems to be: "Dummy Link Target".
> When i don't set details (which means details is 2) then i don'= ;t have a
> "UDSEntry::UDS_LINK_DEST" at all. That leads me to think tha= t this
> UDS_LINK_DEST might not be needed. Can i safely remove the
> "UDSEntry::UDS_LINK_DEST" from the details =3D=3D 0 code pat= h?
> Patch is here: http://paste.kde.org/pad68d0af/

That's not a fix, that's removing a feature instead of fixing= it :-)

UDS_LINK_DEST should only be set for symlinks.
Are you saying that ep->d_type & DT_LNK is true for normal files too= ?
Ah I see:
This should say ep->d_type =3D=3D DT_LNK, it's not a bitfield.
(DT_LNK is 10, DT_REG is 8)
Same for the other tests for d_type, they should all use =3D=3D then.
Can you test if that fixes what you're seeing, and commit (to 4.11) if = so?
Thanks.

--
David Faure, faure@kde.o= rg, http://www.d= avidfaure.fr
Working on KDE, in particular KDE Frameworks 5


I'm doing a bit of thread hijacking now (funny since i made it in = the first place ;p)
Besides the line you said i also changed the lin= e above. Hence asking for a "OK" to commit.
Compile tested on 4.11 and works. The KIO Testcases run just fin= e as well though i doubt they test for this case.

Then a few = questions for frameworks. How do i merge this change back in frameworks?

Note: i&= #39;m right now making a unittest for this specific case in frameworks, not= for 4.11. Just a general "udsentrytest" which should later be ex= tended to cover more of UDSEntry.

--001a11c3ec70dee52e04e6e509c0--