On Sun, 14.11.10 10:41, Mikkel Kamstrup Erlandsen (mikkel.kamst...@gmail.com)
wrote:
>
> On 13 November 2010 23:28, Lennart Poettering wrote:
> > On Sat, 13.11.10 23:12, Mikkel Kamstrup Erlandsen
> > (mikkel.kamst...@gmail.com) wrote:
> >
> >> It's not totally clear from the discussions on thi
On 14 November 2010 02:09, Oswald Buddenhagen wrote:
> On Sat, Nov 13, 2010 at 11:28:08PM +0100, Lennart Poettering wrote:
>> On Sat, 13.11.10 23:12, Mikkel Kamstrup Erlandsen
>> (mikkel.kamst...@gmail.com) wrote:
>> > I'd rather like something more deterministic. "When there are no
>> > file han
On 13 November 2010 23:28, Lennart Poettering wrote:
> On Sat, 13.11.10 23:12, Mikkel Kamstrup Erlandsen (mikkel.kamst...@gmail.com)
> wrote:
>
>> It's not totally clear from the discussions on this list, what kind of
>> items you intend to go in XDG_USER_DIR? As I read it we are mainly
>> talkin
On Sat, Nov 13, 2010 at 11:28:08PM +0100, Lennart Poettering wrote:
> On Sat, 13.11.10 23:12, Mikkel Kamstrup Erlandsen (mikkel.kamst...@gmail.com)
> wrote:
> > I'd rather like something more deterministic. "When there are no
> > file handles on a file it's deleted" - might be too aggressive, but
On Sat, 13.11.10 23:12, Mikkel Kamstrup Erlandsen (mikkel.kamst...@gmail.com)
wrote:
> It's not totally clear from the discussions on this list, what kind of
> items you intend to go in XDG_USER_DIR? As I read it we are mainly
> talking sockets, fifos, pid-files and such. However what about stuff
On 6 November 2010 23:03, Lennart Poettering wrote:
> Heya,
>
> Ryan Lortie and I have been sitting down here at the GNOME Summit and
> have discussed an older proposal that was posted on the XDG ML by Ryan a
> while back, regarding definition of a directory where user applications
> can store run
Em Quinta-feira, 11 de Novembro de 2010, às 19:22:33, Nicolas Mailhot
escreveu:
> Le jeudi 11 novembre 2010 à 00:18 +0100, Thiago Macieira a écrit :
> > On Wednesday, 10 de November de 2010 22:17:40 Ryan Lortie wrote:
> > > /tmp is also often used to store "largeish" things like downloads in
> > >
Le jeudi 11 novembre 2010 à 00:18 +0100, Thiago Macieira a écrit :
> On Wednesday, 10 de November de 2010 22:17:40 Ryan Lortie wrote:
> > /tmp is also often used to store "largeish" things like downloads in
> > progress.
>
> I've had /tmp in tmpfs for over 4 years now and I barely ever needed it
On Wednesday, 10 de November de 2010 22:17:40 Ryan Lortie wrote:
> /tmp is also often used to store "largeish" things like downloads in
> progress.
I've had /tmp in tmpfs for over 4 years now and I barely ever needed it
extended. I think the only app that did need it was the VMWare Server, becaus
On Wed, 10.11.10 16:17, Ryan Lortie (de...@desrt.ca) wrote:
>
> On Wed, 2010-11-10 at 20:37 +0100, Lennart Poettering wrote:
> > Mhmm, I don't think we should.
> >
> > TMPDIR influences tmpnam(), however that function kinda expects a common
> > /tmp namespace anyway, so redirecting this is not n
On Wed, 2010-11-10 at 20:37 +0100, Lennart Poettering wrote:
> Mhmm, I don't think we should.
>
> TMPDIR influences tmpnam(), however that function kinda expects a common
> /tmp namespace anyway, so redirecting this is not necessary.
>
> I think we shouldn't break assumptions about $TMPDIR, for e
On Wed, 10.11.10 15:09, Bill Nottingham (nott...@redhat.com) wrote:
> > TMPDIR influences tmpnam(), however that function kinda expects a common
> > /tmp namespace anyway, so redirecting this is not necessary.
> >
> > I think we shouldn't break assumptions about $TMPDIR, for example that
> > it m
Lennart Poettering (mz...@0pointer.de) said:
> > > It isn't. Most distros clean up that dir already periodically, and with
> > > systemd we will unify that and make it a core part of the basic
> > > system. systemd will apply the same cleanup rules to /var/run/user as to
> > > /tmp.
> >
> > Would
On Wed, 10.11.10 14:13, Bill Nottingham (nott...@redhat.com) wrote:
>
> Lennart Poettering (mz...@0pointer.de) said:
> > > And how is this different from /tmp ?
> >
> > It isn't. Most distros clean up that dir already periodically, and with
> > systemd we will unify that and make it a core part
Lennart Poettering (mz...@0pointer.de) said:
> > And how is this different from /tmp ?
>
> It isn't. Most distros clean up that dir already periodically, and with
> systemd we will unify that and make it a core part of the basic
> system. systemd will apply the same cleanup rules to /var/run/user
On Wed, 2010-11-10 at 01:26 +0100, Lennart Poettering wrote:
> If somebody wants to add that to CK then that is fine. However, I do
> believe the right place for this is actually systemd, since we can
> safely bind the per-user systemd instance, the dbus user bus, the
> existance of XDG_RUNTIME_DIR
On Wed, 10.11.10 01:05, Patryk Zawadzki (pat...@pld-linux.org) wrote:
>
> On Wed, Nov 10, 2010 at 12:01 AM, Lennart Poettering
> wrote:
> > Note that XDG_RUNTIME_DIR needs to be implemented in some lower-level
> > part of the OS anyway (e.g. on Linux: systemd).
>
> Why systemd and not for exam
On Wed, Nov 10, 2010 at 12:01 AM, Lennart Poettering wrote:
> Note that XDG_RUNTIME_DIR needs to be implemented in some lower-level
> part of the OS anyway (e.g. on Linux: systemd).
Why systemd and not for example ConsoleKit - a standard component of a
desktop machine?
--
Patryk Zawadzki
__
On Tue, 09.11.10 16:35, Ryan Lortie (de...@desrt.ca) wrote:
>
> On Sat, 2010-11-06 at 23:03 +0100, Lennart Poettering wrote:
> > - The directory may be deleted (and should be deleted) after the user
> > fully logged off or the machine is shut down.
>
> I'd say must.
>
> It's useful to know that
On Tue, 09.11.10 14:02, Ryan Lortie (de...@desrt.ca) wrote:
> On Tue, 2010-11-09 at 20:53 +0200, Rémi Denis-Courmont wrote:
> > And how is this different from /tmp ?
>
> It's worse than tmp because the runtime dir is on tmpfs and /tmp is
> usually on disk.
(note that I think in the long run we p
On Tue, 09.11.10 20:53, Rémi Denis-Courmont (r...@remlab.net) wrote:
>
> Le mardi 9 novembre 2010 20:48:34 Ryan Lortie, vous avez écrit :
> > The problem is that people often leave themselves logged in for weeks or
> > months at a time and that the directory is meant to be located on a
> > tmpfs.
On Tue, 09.11.10 16:35, David Zeuthen (zeut...@gmail.com) wrote:
>
> Hey,
>
> On Sat, Nov 6, 2010 at 6:03 PM, Lennart Poettering wrote:
> > - It is owned by the user and the user is the only one having write
> > access to it
>
> Your current proposal allows an implementation where other users
On Tue, 09.11.10 10:13, Kevin Krammer (kevin.kram...@gmx.at) wrote:
> > Of course, right now it is not that easy on Linux to get the necessary
> > information from the kernel to implement these tests. However, at last
> > for the wallclock time change test this will change shortly.
>
> Hmm, doesn
On Tue, 09.11.10 04:20, Lennart Poettering (mz...@0pointer.de) wrote:
>
> On Sun, 07.11.10 11:26, Ryan Lortie (de...@desrt.ca) wrote:
>
> > > What if the system resumes from suspend after 12 hours and the OS job to
> > > clean
> > > the directory is executed before any of the apps had a chance
On Sat, 2010-11-06 at 23:03 +0100, Lennart Poettering wrote:
> - The directory may be deleted (and should be deleted) after the user
> fully logged off or the machine is shut down.
I'd say must.
It's useful to know that the directory will have been cleaned out in the
case that the user dbus and o
Hey,
On Sat, Nov 6, 2010 at 6:03 PM, Lennart Poettering wrote:
> - It is owned by the user and the user is the only one having write
> access to it
Your current proposal allows an implementation where other users can
read or enumerate the directory. This is bad. Please require e.g. mode
0700.
On Tue, 2010-11-09 at 20:53 +0200, Rémi Denis-Courmont wrote:
> And how is this different from /tmp ?
It's worse than tmp because the runtime dir is on tmpfs and /tmp is
usually on disk.
Note also that /tmp *does* have periodic cleanup. Check your distro's
cron and/or see the manpage for the tmp
Le mardi 9 novembre 2010 20:48:34 Ryan Lortie, vous avez écrit :
> The problem is that people often leave themselves logged in for weeks or
> months at a time and that the directory is meant to be located on a
> tmpfs.
>
> Mix these two facts together with the fact that buggy applications are
> ex
hi Bill,
On Tue, 2010-11-09 at 10:19 -0500, Bill Nottingham wrote:
> This is the part of the spec that I don't clearly agree with - if it's
> already being automatically cleaned up at session end, additional time-based
> cleanups is likely overkill.
The problem is that people often leave themselv
Kevin Krammer (kevin.kram...@gmx.at) said:
> Since you guys have put this auto delete on age feature into the list you
> probably have a good use case for it. Maybe you could elaborate on it so we
> others can also take it into our considerations.
This is the part of the spec that I don't clear
On Tue, Nov 9, 2010 at 2:38 PM, Thiago Macieira wrote:
> All one needs to do is get both the wall clock and monotonic clock values and
> compare the difference to the last difference computed. If there was a
> considerable jump, skip this cleaning up.
A more robust solution would be to accumulate
Em Terça-feira 09 Novembro 2010, às 10:13:26, Kevin Krammer escreveu:
> I guess it depends whether common methods of sleeping are based on actual
> time, i.e. do select/poll/sleep return when having been given a timeout of
> 6h and the system was suspended during that time?
>
> > Of course, right
On Tuesday, 2010-11-09, Lennart Poettering wrote:
> On Sun, 07.11.10 11:26, Ryan Lortie (de...@desrt.ca) wrote:
> > > What if the system resumes from suspend after 12 hours and the OS job
> > > to clean the directory is executed before any of the apps had a chance
> > > to update mtime?
> >
> > Go
On Sun, 07.11.10 11:26, Ryan Lortie (de...@desrt.ca) wrote:
> > What if the system resumes from suspend after 12 hours and the OS job to
> > clean
> > the directory is executed before any of the apps had a chance to update
> > mtime?
>
> Good point. We could specify 6/12 hours as measured by
hi Kevin,
Thanks for your comments.
On Sun, 2010-11-07 at 16:15 +0100, Kevin Krammer wrote:
> Maybe XDG_RUNTIME_HOME, since all other user specific directory variables in
> the spec are suffixed with _HOME?
All of the other home directories are part of the user's home directory
(at least by def
On Saturday, 2010-11-06, Lennart Poettering wrote:
> Heya,
>
> Ryan Lortie and I have been sitting down here at the GNOME Summit and
> have discussed an older proposal that was posted on the XDG ML by Ryan a
> while back, regarding definition of a directory where user applications
> can store runt
Heya,
Ryan Lortie and I have been sitting down here at the GNOME Summit and
have discussed an older proposal that was posted on the XDG ML by Ryan a
while back, regarding definition of a directory where user applications
can store runtime files and other file objects (sockets, ...) in. That
direct
37 matches
Mail list logo
