On Mon, Apr 15, 2013 at 9:56 PM, David Faure wrote:
> On Monday 15 April 2013 21:40:52 Jerome Leclanche wrote:
> > Ah sorry, I thought you wanted to store it in multiple separate files :)
>
> No, TRASH_DIR/directorysizes will contain the multiple lines I showed in my
> email.
>
> > The simple fil
hi David,
On 2013-04-15 18:47, David Faure wrote:
16950 15803468 Documents
2467 15803582 Another_Folder
One thing I forgot to ask for a clarification on earlier, and certainly
something that we should spell out in the spec: what do we mean by
'size'? Sum of byte-sizes of all files, or 'disk
On Monday 15 April 2013 21:40:52 Jerome Leclanche wrote:
> Ah sorry, I thought you wanted to store it in multiple separate files :)
No, TRASH_DIR/directorysizes will contain the multiple lines I showed in my
email.
> The simple file format is nice however I have a small concern about
> extensibi
Ah sorry, I thought you wanted to store it in multiple separate files :)
The simple file format is nice however I have a small concern about
extensibility; any new value added is going to break backwards
compatibility, unless we specify that additional values may be eventually
added.
Performance-w
On Monday 15 April 2013 17:36:34 Jerome Leclanche wrote:
> Why can't the current .trashinfo files be reused, with new keys added?
So that we open and parse only one file, instead of 1.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
On mån, 2013-04-15 at 18:47 +0200, David Faure wrote:
> It turns out that the trash spec already uses %-encoding: for the path stored
> in the trashinfo file.
>
> So we discussed it a bit more and came up with this update:
>
> Let's not use the desktop entry standard for this, but a simple text
Why can't the current .trashinfo files be reused, with new keys added?
J. Leclanche
On Mon, Apr 15, 2013 at 4:47 PM, David Faure wrote:
> It turns out that the trash spec already uses %-encoding: for the path
> stored
> in the trashinfo file.
>
> So we discussed it a bit more and came up with
It turns out that the trash spec already uses %-encoding: for the path stored
in the trashinfo file.
So we discussed it a bit more and came up with this update:
Let's not use the desktop entry standard for this, but a simple text format,
where each line is:
<%-encoded-path>
Technically % enc
Ok,
thanks, but since it's mixing a directory specially for use by one user,
and fuse-workspace is running as another user, this is not a good idea.
In other words: the mount directory "fuse-workspace/Network" does not belong
in /run/user/{username or userid}. I will use another directory in
stead
On mån, 2013-04-15 at 16:28 +0200, Bastien Nocera wrote:
> Em Mon, 2013-04-15 às 14:36 +0200, Alexander Larsson escreveu:
> > On mån, 2013-04-15 at 14:25 +0200, Ryan Lortie wrote:
> > > hi,
> > >
> > > On 2013-04-15 13:43, Alexander Larsson wrote:
> > > > On mån, 2013-04-15 at 10:19 +0200, Ryan Lo
Em Mon, 2013-04-15 às 14:36 +0200, Alexander Larsson escreveu:
> On mån, 2013-04-15 at 14:25 +0200, Ryan Lortie wrote:
> > hi,
> >
> > On 2013-04-15 13:43, Alexander Larsson wrote:
> > > On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
> > >> No strong objections to turning it into unix-times
Le lundi 15 avril 2013, à 12:31 +0200, David Faure a écrit :
> IMHO we could also add more allowed characters to the spec, but experience
> tells me
> that trying to get stuff into the desktop entry spec is pretty hard. Maybe at
> the next freedesktop
> meeting, when we have more people involved
On segunda-feira, 15 de abril de 2013 12.35.48, Stef Bon wrote:
> howdo I get this environment var from the specific session to the
> fuse-workspace process??
Ask for it.
If your out-of-session process is communicating with a process in-session, ask
it where it would like to see the files stored
On mån, 2013-04-15 at 14:25 +0200, Ryan Lortie wrote:
> hi,
>
> On 2013-04-15 13:43, Alexander Larsson wrote:
> > On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
> >> No strong objections to turning it into unix-timestamp-in-UTC though.
> >
> > N! The timestamp timezone of a mtime is und
hi,
On 2013-04-15 13:43, Alexander Larsson wrote:
On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
No strong objections to turning it into unix-timestamp-in-UTC though.
N! The timestamp timezone of a mtime is undefined, and may be
different from the actual timezone of the computer do
On Mon, 15.04.13 12:35, Stef Bon (stef...@gmail.com) wrote:
>
> Aha,
>
> right! Thanks.
>
> This is set in the environment of the user's shell.
>
> Since my app fuse-workspace is a seperate service, and reacting on
> login/logout events by watching:
> a. the directory /run/systemd/users for sy
On Mon, 15.04.13 10:29, Stef Bon (stef...@gmail.com) wrote:
> Hi,
>
> I'm working on a sollutution which creates network access, fuse-workspace.
> It's ssimular to gnome vfs, and also based upon a fuse filesystem.
>
> Supported is access to smb, and browsing the shares is possible through
> libs
On mån, 2013-04-15 at 10:19 +0200, Ryan Lortie wrote:
> hi,
>
> On 2013-04-15 10:07, Alexander Larsson wrote:
> > 1: Using sha1 seems wrong to me. There is no need to get an even
> > distribution of the keys (like for thumbnail subdirectories), and a sha1
> > is slow to calculate. Also, if you eve
Aha,
right! Thanks.
This is set in the environment of the user's shell.
Since my app fuse-workspace is a seperate service, and reacting on
login/logout events by watching:
a. the directory /run/systemd/users for systemd
b.consolekit if available
or a
c. pam module special for this (pam_script))
Adding the % character in there is probably not a big deal; is there any
software in the world that actually validates trashinfo files?
Additionally, the current trash spec only says "The format of this file is
similar to the format of a desktop entry file", so we can make a note of it
being suppor
On Monday 15 April 2013 10:17:14 Jerome Leclanche wrote:
> Do the keys accept %? uri-encoding them would be the obvious solution here.
Yes, it would have been, but this isn't a supported character...
see last section of
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html
IMHO
$XDG_RUNTIME_DIR is what you're looking for, but it's not guaranteed to be
set (it really should be, but...)
J. Leclanche
On Mon, Apr 15, 2013 at 8:29 AM, Stef Bon wrote:
> Hi,
>
> I'm working on a sollutution which creates network access, fuse-workspace.
> It's ssimular to gnome vfs, and also
Do the keys accept %? uri-encoding them would be the obvious solution here.
I'm also very uncomfortable with the sha1 bit, but apart from that
everything looks good.
J. Leclanche
On Mon, Apr 15, 2013 at 9:11 AM, David Faure wrote:
> On Monday 15 April 2013 10:19:55 Bastien Nocera wrote:
> > Em
On Monday 15 April 2013 10:19:55 Bastien Nocera wrote:
> Em Mon, 2013-04-15 às 10:07 +0200, Alexander Larsson escreveu:
> > On sön, 2013-04-14 at 23:48 +0200, David Faure wrote:
> > > To implement a maximum size for the trash directory, one needs to check
> > > the
> > > size every time a new item
Hi,
I'm working on a sollutution which creates network access, fuse-workspace.
It's ssimular to gnome vfs, and also based upon a fuse filesystem.
Supported is access to smb, and browsing the shares is possible through
libsmbclient or cifs. In the latest case fuse-workspace mounts the
remote share
Em Mon, 2013-04-15 às 10:07 +0200, Alexander Larsson escreveu:
> On sön, 2013-04-14 at 23:48 +0200, David Faure wrote:
> > To implement a maximum size for the trash directory, one needs to check the
> > size every time a new item is being trashed. With the current spec, the
> > only
> > solution
On sön, 2013-04-14 at 23:48 +0200, David Faure wrote:
> To implement a maximum size for the trash directory, one needs to check the
> size every time a new item is being trashed. With the current spec, the only
> solution is to do a recursive traversal, which is pretty expensive.
> To make this e
27 matches
Mail list logo
