SlaveBase::rename issues

[Kevin Ottens]

Le lundi 23 juillet 2007, Jeff Mitchell a écrit :
> [...]
> To do this the entries listDir returns in pmp:/// have KIO::NAME and
> KIO::URL properties.  So the NAME property is what's shown, and
> double-clicking on it takes it to the device-specific URL as expected.
>
> The problem pops up when I attempt to allow a rename on these devices,
> so that users can set friendly names that will be stored on the device
> (many libraries support this function).  The pseudocode goes like this:
>
> PMPProtocol::rename( src, dest, overwrite)
>   //if certain conditions are met such that I know that
>   //they are trying to do a top-level rename...
>   deviceFor(src)->setFriendlyName( nameFrom( dst ))
>   emit finished()
>   return
>
> Not emitting finished causes things to go awry, and emitting finished
> causes the displayed name to be modified.
>
> Unfortunately, this doesn't just modify the NAME field but the URL field
> as well.  So when the user then tries to access the device, the URL is
> invalid.
>
> I would contend that if a UDSEntry has both a defined NAME field and a
> defined URL field that, since the user will be attempting to modify the
> displayed name, only the NAME field should be modified.  Modifying the
> URL is totally meaningless in this case.

Ok, at first I wondered why I didn't experience the same thing than you while 
using the same "trick" for renaming in kio media. In fact it's because it 
also poke KDirNotify on such renames, which forces the filemanager to re-list 
or re-stat (depending on the case) and update the information.

I agree that it's unobvious and undesired behavior though.

> I can see a few ways to work around this:
> 1) Fix things so that in the case that a display name is set, a
> modification to that name only affects the display name.

The problem being that rename() is the equivalent of mv in cli. So it's used 
both to rename in place something _and_ to move it in another folder (so the 
url effectively changes).

That said, maybe we could use as an heuristic the following:
if the file has a NAME entry and only the file part of the url changed then 
change the NAME entry otherwise change the URL entry.

That's probably not the final solution we want to implement here, but that 
looks like the right direction to me. Comments are welcome, in particular to 
put in light side-effects in the file dialog or file managers of such an 
operation. I lack some visibility in konqueror behavior here for instance.

> 2) Have some way to force a re-listDir() on that directory at the end of
> the rename function (is there a way to do this already that I don't know
> about?)

KDirNotify, see above.

> 3) Have some way to choose which fields in a UDSEntry are updated by a
> rename (is there a way to do this already that I don't know about?)

Not sure it's a good idea, makes the stuff very complicated while it's really 
about only NAME and URL. If we find a solution for the general case I'd be 
for it (1. looking like a good candidate IMO).

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."