> On Oct. 14, 2014, 11:13 p.m., David Faure wrote:
> > kioslave/trash/trashimpl.cpp, line 170
> > <https://git.reviewboard.kde.org/r/120573/diff/6/?file=318520#file318520line170>
> >
> > Shouldn't this return false like the other blocks?
> >
> > And then I would swap the if and else blocks, removing the '!' in the
> > condition... so that all if() blocks follow the same pattern.
> >
> > I see that the code below tries to cope with the case where we couldn't
> > create KDE.trash ... but then we shouldn't set any error code, if we
> > fallback to another solution.
> >
> > However I'm not sure I understand why this could happen though. Why
> > wouldn't we be able to create "KDE.trash" but we would be able to create
> > "info"? Well, this would be the case if KDE.trash existed already and was
> > owned by another user, but then the same could happen with "info"...
>
> René J.V. Bertin wrote:
> Modified as suggested. I agree that the error shouldn't occur. Normally
> it *cannot* occur for the reason you indicate unless another user wrote an
> entry in this user's Trash explicitly and "by hand". However I'm not sure how
> KDE_mkdir handles a situation in which a (read-only) _file_ of the same name
> is already present, owned by the same user. While that is unlikely it's not
> entirely impossible either.
>
> David Faure wrote:
> mkdir will fail with errno==EEXIST if a dir (or file) already exists with
> the same name, anyway (no matter what the permissions and ownership are).
>
> I just don't like that this code can use either trashPath or
> trashPath+"/KDE.trash", and has to handle both cases everywhere, including
> "hacks" like "if endsWith("/KDE.trash")".
> We should pick one way and stick to it, anything else increases
> complexity and therefore the risk of bugs.
>
> "remove the subdirectory we couldn't create and use the standard KDE
> infrastructure" is weird if you have decided that the "KDE infrastructure" on
> OS X *is* trashdir+"/KDE.trash".
>
> René J.V. Bertin wrote:
> Point taken.
>
> Now the question is, how am I going to implement a function that
> (re)creates the infrastructure if it has been deleted? Is trashimpl.h part of
> the external API, i.e. can I add a function to TrashImpl - and would that
> have to be a function available everywhere (but a stub on all but OS X), or a
> function that only exists on OS X?
>
> Thomas Lübking wrote:
>
> http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/classTrashImpl.html
>
> On the $TRASH/KDE.trash issue and in general:
> OS_X stores trashed files directly in ~/.Trash, I take?
> In that case i foresee a general issue (maybe academic, but possible)
> with the approach to store the KDE trash stuff there (which OSX will take as
> trashed files).
>
> What happens if you delete a file named "info" or "files" or "KDE.trash"?
> In either case you'd likely run into a conflict? Ie. either OS_X cannot
> trash the new file (for there's a directory of that name) or OS_X
> overrides/invalidates the entire KDE trash or OS_X creates such file and you
> can't add the KDE stuff there.
> Yesno?
>
> In case: how does the OS_X trash handle hidden (.*) files?
> Assuming it doesn't put hidden files dotted into the trash, how does it
> react when adding a hidden file there (whether .info, .files or .KDE.trash)?
>
> René J.V. Bertin wrote:
> In fact, it works exactly the way the KDE trash works, except for the
> restore info which (I presume) is stored in the file metadata.
> So:
>
> - deleting a file that has the same name as a file already in the trash
> will 1) rename that file to something like "name 1" and 2) move that file
> into the trash. (I've been able to see that happen when the system is very
> busy). In short, it's only if someone already put a KDE.trash in the trash
> that we'd into trouble, unless it's a directory.
> - Why wouldn't it put hidden files there? Again, the Finder works like
> Dolphin or Nautilus: hidden files are nothing special, they're just not shown
> in the Finder (nor in file selection dialogs).
>
> I'm not sure if the trash would show as non-empty if we store everything
> under ~/.Trash/.KDE.trash but if it does we have the problem that the user
> won't understand why when s/he opens the Trash in the Finder. And if it
> doesn't we're more or less back where we started.
> I think it's important that KDE waste becomes visible in the OS X Trash,
> preferably in a subdirectory.
>
> Thomas Lübking wrote:
> > Why wouldn't it put hidden files there?
>
> Counterfeit - there's only limited reason to hide a file in the trash
> (the kioslave simply shows them), so I could have assumed it's renamed .foo
> -> _.foo or so.
>
> Does OS_X consider an empty directory in ~/.Trash a non-empty trash
> (notably if it has no meta/restorage data)?
>
> The "ideal" solution to me seems to ensure there's always OUR (we can
> hardly re-use a directory the user deleted there via the OS_X tash)
> ~/.Trash/KDE.trash dir (so OS_X will avoid that name) and convince the OS_X
> trash to ignore it while empty.
>
> If we cannot make OS_X ignore it, such directory must be created avoiding
> any collision w/ relgularily deleted files/dirs (ie. if there's such file or
> dir, *we* must becom KDE.trash_1 or similar)
>
> The tricky part will be to (persistently) export the legal KDE.trash*
> path to all clients (config key? but it must be updated by any running
> process whenever the path changes)
The situation with hidden files is a weird one, in fact. I just created a
`.file`, `.dir` and `.dir/file` in ~/.Trash . As I half-expected, the Finder
kept considering its Trash to be empty (and so didn't allow it to be emptied
either) because it's configured to ignore "hidden" files. So far so good (or
not...). But as soon as there's recognised content and you empty the Trash,
those hidden entries got deleted too.
So no, hidden entries don't get special treatment in the Finder's Trash, but
it's also much harder (probably impossible) to get them in there through the
Finder, and there's no easy way to get them to be displayed either ("show
hidden files").
I wouldn't worry about these.
> we can hardly re-use a directory the user deleted there via the OS_X tash
Well, yes and no. The previous one will be gone after emptying the Trash,
contents included, but I've been taking the point of view that we can recreate
it when needed. It's trash, there's no particular issue with wrapping it up
nicely or not, my only concern is that KDE's trash can be emptied with the rest
of the trash, and without having to fire up a KDE application to do that. (If
all KDE apps that offer to move items to the wastebin also had a function to
empty it I wouldn't have thought to start working on this!)
The ideal solution would in fact be to figure out how to store the .trashinfo
data the native way, allowing the Finder to handle restores too, at least if
that's possible. I'd propose to do that in a second step (it might well require
making a trip to ObjC land); let's first see how far we can go with the simpler
approach I'm taking here.
- René J.V.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120573/#review68418
-----------------------------------------------------------
On Oct. 15, 2014, 6:26 p.m., René J.V. Bertin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120573/
> -----------------------------------------------------------
>
> (Updated Oct. 15, 2014, 6:26 p.m.)
>
>
> Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.
>
>
> Repository: kde-runtime
>
>
> Description
> -------
>
> KDE on OS X does not handle the desktop session (no "Plasma") nor can it rely
> on XDG to obtain the proper paths to use for something like the trash. As a
> result, all applications that propose to move things they manage to the
> wastebin (Dolphin, but also digiKam) will store those items in a place that
> has no particular meaning on OS X, and that will thus tend to fill up.
>
> OS X stores trash in one of several locations. Files trashed from the boot
> volume (and/or the volume containing $HOME, I don't actually know that) end
> up in `~/.Trash`. Files deleted from other volumes end up in
> `/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless
> whether it's an external or a remote drive; only mounted NFS shares are
> handled differently) and uid the numerical user id. Permissions on `.Trashes`
> are the same as those expected by KDE.
>
> The kio_trash kioslave appears to support several actual trash directory
> locations, just like OS X. `TrashImpl::init()` creates a standard trash in
> `~/.local/share/Trash` (at least under OS X) but also
> `TrashImpl::trashForMountPoint()` that is used in cases I have not yet
> encountered.
>
> On OS X, my modified `TrashImpl::init()` sets the standard trash directory to
> `~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as
> required, because they will of course be deleted when the user empties the OS
> X trash. `TrashImpl::fileRemoved()` has been modified to call a new function,
> `deleteEmptyTrashInfraStructure` to delete the KDE trash's internal
> infrastructure when the wastebin is empty so that OS X also sees the trash as
> emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature
> actually works, as expected as far as I can tell).
>
> Remains to be done:
> - determine in what cases `trashForMountPoint()` is used, and finish the
> modifications for it to use `/.Trashes/uid/KDE.trash`
>
>
> Diffs
> -----
>
> kioslave/trash/kcmtrash.cpp f4811fd
> kioslave/trash/trashimpl.h bc68723
> kioslave/trash/trashimpl.cpp 30ee05b
>
> Diff: https://git.reviewboard.kde.org/r/120573/diff/
>
>
> Testing
> -------
>
> On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested
> actions are
> - move items to wastebin from $HOME and a directory on a different volume
> - restore items to both places
> - empty wastebin through Dolphin
> - empty OS X trashcan
>
>
> Thanks,
>
> René J.V. Bertin
>
>
