On Sat, 2010-02-13 at 22:12 -0800, Gordon Messmer wrote:
> On 02/12/2010 05:56 PM, Patrick O'Callaghan wrote:
> > One of the comments to the LWN article also mentions the case of Apple
> > allowing these links for the sake of their Time Machine backup system (I
> > think it's restricted to that spe
On 02/12/2010 05:56 PM, Patrick O'Callaghan wrote:
> One of the comments to the LWN article also mentions the case of Apple
> allowing these links for the sake of their Time Machine backup system (I
> think it's restricted to that special case so it doesn't run the risk of
> a general-purpose featu
On 02/12/2010 09:00 PM, Suvayu Ali wrote:
>
> On some more experimentation I realised this is how `cat' behaves, it
> doesn't show the lines written the first time, it only shows the stdin
> which is perfectly reasonable. My apologies :-p
Actually, cat doesn't show anything at all. Your terminal
From: "Marko Vojinovic"
Sent: Saturday, 2010/February/13 05:44
> On Saturday 13 February 2010 06:30:55 jdow wrote:
>> It's even worse than that, Marko.
>>
>> You have a directory tree /a/b/c/d. You create a hard link to directory
>> /a/b inside of d. You get /a/b/c/d/b/c/d/b/c/d
>>
>> NOW y
From: "Patrick O'Callaghan"
> This is what I referred to in my original answer. Permitting arbitrary
> links to directories allows us to create structures which are
> disconnected from the root of the tree, which is of course Bad.
Of course, and now it's not being ignored, I hope.
{^_-}
--
us
On Saturday 13 February 2010 06:30:55 jdow wrote:
> From: "Marko Vojinovic"
> > Deleting directories is a textbook example. In order to delete a
> > directory,
> > you first have to delete all files and subdirectories that it contains,
> > and once
> > it is empty, delete the directory itself. So
On Fri, 2010-02-12 at 22:30 -0800, jdow wrote:
> From: "Marko Vojinovic"
> Sent: Friday, 2010/February/12 20:12
>
>
> > On Saturday 13 February 2010 00:09:38 Suvayu Ali wrote:
> >> On Friday 12 February 2010 06:06 AM, Marko Vojinovic wrote:
> >> > Now, hard links are not allowed for directories
On Sat, 2010-02-13 at 05:20 +, g wrote:
> Patrick O'Callaghan wrote:
>
> > cat > foo &
> > rm foo
> > lsof +L1 -s
> >
> > When I do this the "cat" process shows up (and foo is marked as
> > deleted). You can then reconnect to "cat" (using fg) and write stuff
> > into the "non-existent" file.
From: "Marko Vojinovic"
Sent: Friday, 2010/February/12 20:12
> On Saturday 13 February 2010 00:09:38 Suvayu Ali wrote:
>> On Friday 12 February 2010 06:06 AM, Marko Vojinovic wrote:
>> > Now, hard links are not allowed for directories since they would allow
>> > for creation of loops (a director
Patrick O'Callaghan wrote:
> cat > foo &
> rm foo
> lsof +L1 -s
>
> When I do this the "cat" process shows up (and foo is marked as
> deleted). You can then reconnect to "cat" (using fg) and write stuff
> into the "non-existent" file.
'cat > foo &', will create a file 'foo' in directory and in b
On Friday 12 February 2010 08:12 PM, Marko Vojinovic wrote:
> On Saturday 13 February 2010 00:09:38 Suvayu Ali wrote:
>> On Friday 12 February 2010 06:06 AM, Marko Vojinovic wrote:
>>> Now, hard links are not allowed for directories since they would allow
>>> for creation of loops (a directory cont
On Friday 12 February 2010 07:45 PM, Patrick O'Callaghan wrote:
> On Fri, 2010-02-12 at 19:20 -0800, Suvayu Ali wrote:
>>> $ fg %1
>>> cat> foo
>>> testing deleted files
>>> ^Z
>>> [1]+ Stopped cat> foo
>>> $ lsof +L1 -s
>>> COMMAND PID USER FD TYPE DEVICE SIZE NLINK NODE
On Saturday 13 February 2010 00:09:38 Suvayu Ali wrote:
> On Friday 12 February 2010 06:06 AM, Marko Vojinovic wrote:
> > Now, hard links are not allowed for directories since they would allow
> > for creation of loops (a directory containing itself), which is a Bad
> > Idea, since it breaks recurs
On Fri, 2010-02-12 at 19:20 -0800, Suvayu Ali wrote:
> On Friday 12 February 2010 05:57 PM, Patrick O'Callaghan wrote:
> > On Fri, 2010-02-12 at 16:42 -0800, Suvayu Ali wrote:
> >> On Friday 12 February 2010 04:36 PM, Suvayu Ali wrote:
> >>> On Friday 12 February 2010 04:07 PM, Patrick O'Callaghan
On Fri, 2010-02-12 at 19:28 -0800, Suvayu Ali wrote:
> > I'm not sure I understand what you're asking here. If something is
> > decided by the kernel, surely it's universal isn't it?
>
> By universal I meant something determined by the filesystem. Would
> the
> restriction still be there if I wer
On Friday 12 February 2010 07:20 PM, Suvayu Ali wrote:
> On Friday 12 February 2010 05:57 PM, Patrick O'Callaghan wrote:
>> On Fri, 2010-02-12 at 16:42 -0800, Suvayu Ali wrote:
>>> On Friday 12 February 2010 04:36 PM, Suvayu Ali wrote:
On Friday 12 February 2010 04:07 PM, Patrick O'Callaghan w
On Friday 12 February 2010 05:56 PM, Patrick O'Callaghan wrote:
> On Fri, 2010-02-12 at 16:02 -0800, Suvayu Ali wrote:
>> On Friday 12 February 2010 05:41 AM, Patrick O'Callaghan wrote:
>>> On Thu, 2010-02-11 at 23:23 -0800, Suvayu Ali wrote:
>> [...]
>> Okay, I now understand the aspect of "." and
On Friday 12 February 2010 05:57 PM, Patrick O'Callaghan wrote:
> On Fri, 2010-02-12 at 16:42 -0800, Suvayu Ali wrote:
>> On Friday 12 February 2010 04:36 PM, Suvayu Ali wrote:
>>> On Friday 12 February 2010 04:07 PM, Patrick O'Callaghan wrote:
Editors can do funny things with backup files in
From: "Patrick O'Callaghan"
Sent: Friday, 2010/February/12 16:07
> On Fri, 2010-02-12 at 15:40 -0800, Suvayu Ali wrote:
>> On Friday 12 February 2010 09:19 AM, Mikkel wrote:
>> > On 02/12/2010 09:29 AM, Bruno Wolff III wrote:
>> >>
>> >> lsof would allow you to find the processes that have the f
On Fri, 2010-02-12 at 16:42 -0800, Suvayu Ali wrote:
> On Friday 12 February 2010 04:36 PM, Suvayu Ali wrote:
> > On Friday 12 February 2010 04:07 PM, Patrick O'Callaghan wrote:
> >> Editors can do funny things with backup files in the interests of
> >> preserving your work. An easier test would be
On Fri, 2010-02-12 at 16:02 -0800, Suvayu Ali wrote:
> On Friday 12 February 2010 05:41 AM, Patrick O'Callaghan wrote:
> > On Thu, 2010-02-11 at 23:23 -0800, Suvayu Ali wrote:
> [...]
> Okay, I now understand the aspect of "." and ".." being the only two
> hardlinks allowed for directories. Howeve
On Friday 12 February 2010 04:36 PM, Suvayu Ali wrote:
> On Friday 12 February 2010 04:07 PM, Patrick O'Callaghan wrote:
>> Editors can do funny things with backup files in the interests of
>> preserving your work. An easier test would be:
>>
>> cat> foo&
>> rm foo
>> lsof +L1 -s
>>
>> When I do th
On Friday 12 February 2010 04:07 PM, Patrick O'Callaghan wrote:
> On Fri, 2010-02-12 at 15:40 -0800, Suvayu Ali wrote:
>> On Friday 12 February 2010 09:19 AM, Mikkel wrote:
>>> On 02/12/2010 09:29 AM, Bruno Wolff III wrote:
lsof would allow you to find the processes that have the files op
On Fri, 2010-02-12 at 15:40 -0800, Suvayu Ali wrote:
> On Friday 12 February 2010 09:19 AM, Mikkel wrote:
> > On 02/12/2010 09:29 AM, Bruno Wolff III wrote:
> >>
> >> lsof would allow you to find the processes that have the files open. And
> >> then
> >> you could kill those processes to release t
On Friday 12 February 2010 06:06 AM, Marko Vojinovic wrote:
> On Friday 12 February 2010 07:23:02 Suvayu Ali wrote:
>> $ ln muse test
>> ln: `muse': hard link not allowed for directory
>>
>> So I did a little searching and found its not exactly a forbidden. So
>> far the closest to an understandabl
On Friday 12 February 2010 05:41 AM, Patrick O'Callaghan wrote:
> On Thu, 2010-02-11 at 23:23 -0800, Suvayu Ali wrote:
>> Hi everyone,
>>
>> When I tried to hardlink a directory today I ran into this,
>>
>> $ ln muse test
>> ln: `muse': hard link not allowed for directory
>>
>> So I did a little se
On 12 February 2010 23:40, Suvayu Ali wrote:
> On Friday 12 February 2010 09:19 AM, Mikkel wrote:
>> On 02/12/2010 09:29 AM, Bruno Wolff III wrote:
>>>
>>> lsof would allow you to find the processes that have the files open. And
>>> then
>>> you could kill those processes to release the space. It
On Friday 12 February 2010 09:19 AM, Mikkel wrote:
> On 02/12/2010 09:29 AM, Bruno Wolff III wrote:
>>
>> lsof would allow you to find the processes that have the files open. And then
>> you could kill those processes to release the space. It looks like you should
>> be able to get size infomation
On 02/12/2010 09:29 AM, Bruno Wolff III wrote:
>
> lsof would allow you to find the processes that have the files open. And then
> you could kill those processes to release the space. It looks like you should
> be able to get size infomation of these files from lsof as well. So one
> could script
On Fri, 2010-02-12 at 07:04 -0800, Don Quixote de la Mancha wrote:
> Actually that is not quite true. A seemingly bizarre and just about
> always surprising but well-documented and surprisingly useful
> requirement of UNIX filesystem symantics is that a file does not
> actually disappear until *tw
Don Quixote de la Mancha wrote:
> The "ln -s" command requires the path of the file to which the link
> will point, and the path of the link itself. But it doesn't care one
> whit whether the linked-to file actually exists. If you can supply a
> path to it, you could symbolically link to anywher
On Fri, Feb 12, 2010 at 07:04:58 -0800,
Don Quixote de la Mancha wrote:
>
> Not just no other user, but no other process of any kind - not even
> your own processes - will be able to locate the deleted files that you
> are holding open. It will be very difficult for naive sysadmins to
> even f
> A hard link is a directory entry that references an inode. Every
> property of the file is represented in the inode, including its type,
> ownership, permissions, size and pointers to the actual data, i.e. the
> directory entry is simply a (name, inode) pair. As such, there can be
> multiple dire
On Fri, Feb 12, 2010 at 5:41 AM, Patrick O'Callaghan
wrote:
> Since it's just a name, there are no restrictions on what it
> contains, in fact it may not point at anything that actually exists, and
> of course can actually create a circular structure.
A Good Time Can Be Had By All, by symbolicall
On Friday 12 February 2010 07:23:02 Suvayu Ali wrote:
> $ ln muse test
> ln: `muse': hard link not allowed for directory
>
> So I did a little searching and found its not exactly a forbidden. So
> far the closest to an understandable explanation/reasoning I came across
> was a discussion in lwn[1]
On Thu, 2010-02-11 at 23:23 -0800, Suvayu Ali wrote:
> Hi everyone,
>
> When I tried to hardlink a directory today I ran into this,
>
> $ ln muse test
> ln: `muse': hard link not allowed for directory
>
> So I did a little searching and found its not exactly a forbidden. So
> far the closest to
Suvayu Ali wrote:
> So my question is how are hardlinks so different from softlinks?
back in 70's when i first started with unix, linking took several times of
rereading of manual before i really understood what and why.
have a look at these 2 links and see if it clears up for you.
http://en
Hi everyone,
When I tried to hardlink a directory today I ran into this,
$ ln muse test
ln: `muse': hard link not allowed for directory
So I did a little searching and found its not exactly a forbidden. So
far the closest to an understandable explanation/reasoning I came across
was a discussio
38 matches
Mail list logo
