Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #181805 > unrolled thread

Automatic updating links?

Back to article view | Back to linux.debian.user

Contents

  Automatic updating links? Rodolfo Medina <rodolfo.medina@gmail.com> - 2017-06-06 13:30 +0200
    Re: Automatic updating links? <tomas@tuxteam.de> - 2017-06-06 13:50 +0200
    Re: Automatic updating links? Darac Marjal <mailinglist@darac.org.uk> - 2017-06-06 14:30 +0200
    Re: Automatic updating links? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-06-06 14:40 +0200
      Re: Automatic updating links? Rodolfo Medina <rodolfo.medina@gmail.com> - 2017-06-06 19:50 +0200
        Re: Automatic updating links? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-06-06 20:00 +0200
          Re: Automatic updating links? Rodolfo Medina <rodolfo.medina@gmail.com> - 2017-06-06 20:20 +0200
            Re: Automatic updating links? davidson@freevolt.org - 2017-06-06 20:50 +0200
              Re: Automatic updating links? davidson@freevolt.org - 2017-06-06 21:10 +0200
            Re: Automatic updating links? Darac Marjal <mailinglist@darac.org.uk> - 2017-06-07 13:20 +0200
              Re: Automatic updating links? Dan Ritter <dsr@randomstring.org> - 2017-06-15 16:20 +0200
        Re: Automatic updating links? David Wright <deblis@lionunicorn.co.uk> - 2017-06-06 21:00 +0200
          Re: Automatic updating links? Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2017-06-06 21:00 +0200
            Re: Automatic updating links? Rodolfo Medina <rodolfo.medina@gmail.com> - 2017-06-06 21:50 +0200
        Re: Automatic updating links? Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> - 2017-06-06 21:00 +0200

#181805 — Automatic updating links?

I wish to create a link to a file that wouldn't break when that file is moved
on elsewhere in the filesystem or renamed, nay the link would automatically
`update' pointing at the new name/address of the file.  Is that possible?
Besides, I wish that form of automatic update also when moving or renaming the
directory where the link itself lives.

Thanks for any help,

Rodolfo

[toc] | [next] | [standalone]

#181807

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jun 06, 2017 at 12:27:06PM +0100, Rodolfo Medina wrote:
> I wish to create a link to a file that wouldn't break when that file is moved
> on elsewhere in the filesystem or renamed, nay the link would automatically
> `update' pointing at the new name/address of the file.  Is that possible?
> Besides, I wish that form of automatic update also when moving or renaming the
> directory where the link itself lives.

Hm. Tough question. The most correct answer is, alas, "no". You'll have to
refine your requirements to understand why.

What shall happen when you modify the file's content? What shall happen
when you split the file into three parts? The link now points to three
files?

Once you have refined the requirements, you might come up with a strategy.
For example, if you consider files as immutable, you might consider storing
their (primary) locations under their (content) hash, kind of what Git
does behind the scenes (and some deduplicating file systems -- this pattern
has come up time and again, cf. "content addressable store"). This might
work as long as the files aren't huge (e.g. videos), where calculating the
hash itself would be prohibitive in terms of time and consumed I/O. If
files are mutable, things become more "interesting" (Git heroically tries
to tackle that, and it works "mostly", but Git's "clients" are mostly
source code files, i.e. a small subset of what files can be.

After you're clear on what you really want to have, you may perhaps find
something "out there" which fits the bill. For example, there's (at least
one) FUSE based file system with a Git backend.

Hope this gives you some ideas.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk2lPcACgkQBcgs9XrR2kZeHQCbBhQjduOGXwr6IGGW9xcZr2LT
5w8An0/HHctW3X3yigRxq2MJ6AGwUVR5
=5vzu
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#181811

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 06, 2017 at 12:27:06PM +0100, Rodolfo Medina wrote:
>I wish to create a link to a file that wouldn't break when that file is moved
>on elsewhere in the filesystem or renamed, nay the link would automatically
>`update' pointing at the new name/address of the file.  Is that possible?
>Besides, I wish that form of automatic update also when moving or renaming the
>directory where the link itself lives.

A hardlink might work here.

A symlink (which many people are familiar with) is, essentially, a small
file which says "I am a pointer to /bin/foo". A hardlink, however, is a
second name for a file ("I am both /bin/foo and /bin/bar"). A hardlink
is possible because of the disconnection between a file's directory
entry (i.e. it's name) and the file's contents.

With a hardlink, it is possible to perform certain actions without
breaking the link. You can move one of the files (this just changes that
particular directory entry), you can rename the directory holding the
file(s) (as this doesn't affect the directory entry at all). In certain
circumstances you can even edit the file - as there is only one "file
contents", both files will show identical changes immediately.

There are some restrictions, though. Some file editing operations
involve deleting the original and replacing it with the modified
version. This will break the hardlink (becasue you're essentially saying
"/bin/foo now points to this file" without updaing what /bin/bar points
to). Also, hardlinks are a file-system-specific feature - that is, you
can't hardlink two files on different filesystems.

>
>Thanks for any help,
>
>Rodolfo
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#181813

On Tue, Jun 06, 2017 at 12:27:06PM +0100, Rodolfo Medina wrote:
> I wish to create a link to a file that wouldn't break when that file is moved
> on elsewhere in the filesystem or renamed, nay the link would automatically
> `update' pointing at the new name/address of the file.  Is that possible?
> Besides, I wish that form of automatic update also when moving or renaming the
> directory where the link itself lives.

There are two types of links in Unix: "hard" links, and "soft" (symbolic)
links.

A symbolic link contains the name of its "target".  When you open the
symlink, the underlying file system drivers see that it's a symlink,
read the target, and rewrite the filename to open the target that the
symlink points to.  For example:

wooledg:~$ ls -ld file
-rw-r--r-- 1 wooledg 563 24 Jul  2  2015 file
wooledg:~$ cat file
line one
line two
match
wooledg:~$ ln -s file slink
wooledg:~$ ls -ld slink
lrwxrwxrwx 1 wooledg wooledg 4 Jun  6 08:18 slink -> file
wooledg:~$ cat slink
line one
line two
match

Now, if I rename "file", the symlink "slink" will no longer point to
the right place:

wooledg:~$ mv file xfile
wooledg:~$ cat slink
cat: slink: No such file or directory

I believe that's what you already knew before asking this question,
but I had to include this information to be sure, because you didn't
actually say what you had already tried.

Now, the other type of link is older and much more subtle.  Hard links
work at the inode level.  To really understand what a hard link is, you
need to understand how directories and inodes work in Unix.

A directory in Unix is (conceptually) just a list of filenames and
inode numbers.  Imagine a telephone book.  You can look up a person's
name, and next to their name is their telephone number.  This is how
Unix directories work.  This is where the name "directory" actually
comes from.  (Phone books are formally called "directories".)

(If you're too young to know what a phone book is... then I don't know
how to help you with that.)

So.  You have a directory, and inside the directory is a file.  Let's
revert back to our original state:

wooledg:~$ rm slink; mv xfile file
wooledg:~$ ls -ld file
-rw-r--r-- 1 wooledg 563 24 Jul  2  2015 file

Now let's create a "hard" link to the file:

wooledg:~$ ln file hlink
wooledg:~$ ls -ld file hlink
-rw-r--r-- 2 wooledg 563 24 Jul  2  2015 file
-rw-r--r-- 2 wooledg 563 24 Jul  2  2015 hlink

See the "2" between the permissions and the owner?  That's the link
count.  That tells us how many hard links there are to the file.  If
we inspect the inode numbers for these two directory entries, we'll
see that they are the same:

wooledg:~$ ls -li file hlink
1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 file
1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 hlink

Same inode number.  They are in fact two different names for the same
*file*.  Both directory entries contain the same inode number, which
is the only thing a directory can tell you.

Now, if I rename the file, let's observe what happens:

wooledg:~$ mv file xfile
wooledg:~$ ls -li xfile hlink
1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 hlink
1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 xfile
wooledg:~$ cat hlink
line one
line two
match

In this case, the renaming of *one* of the hard links did not matter.
The *other* hard link still "points to" the inode that contains the
actual contents.  You can move the hard link ("file") to a subdirectory,
or any other directory inside the file system, and it won't matter.
The hard links still point to the same inode number.

Now, this part is very important: inode numbers are only meaningful
within a single file system.  If you move one of the "files" *outside*
of this file system, then the hard links will no longer reference 
the same file.  If you modify one of them, the other will still contain
a copy of the original content.

wooledg:~$ mkdir /run/user/1000/tmp
wooledg:~$ mv xfile file
wooledg:~$ mv hlink /run/user/1000/tmp
wooledg:~$ ls -lid file /run/user/1000/tmp/hlink
1573283 -rw-r--r-- 1 wooledg     563 24 Jul  2  2015 file
 319746 -rw-r--r-- 1 wooledg wooledg 24 Jul  2  2015 /run/user/1000/tmp/hlink
wooledg:~$ echo "another line" >> /run/user/1000/tmp/hlink
wooledg:~$ cat file
line one
line two
match

At this point, even though the two "files" were orignally hard linked,
that changed when we moved one of them to a different file system.
Now they are simply two files with no relationship to each other.

So... to answer your question, as long as you only have *ONE* file
system to worry about, you can make hard links, and I believe they
will satisfy your stated requirements.

[toc] | [prev] | [next] | [standalone]

#181837

Greg Wooledge <wooledg@eeg.ccf.org> writes:

> On Tue, Jun 06, 2017 at 12:27:06PM +0100, Rodolfo Medina wrote:
>> I wish to create a link to a file that wouldn't break when that file is
>> moved on elsewhere in the filesystem or renamed, nay the link would
>> automatically `update' pointing at the new name/address of the file.  Is
>> that possible?  Besides, I wish that form of automatic update also when
>> moving or renaming the directory where the link itself lives.
>
> There are two types of links in Unix: "hard" links, and "soft" (symbolic)
> links.
>
> A symbolic link contains the name of its "target".  When you open the
> symlink, the underlying file system drivers see that it's a symlink,
> read the target, and rewrite the filename to open the target that the
> symlink points to.  For example:
>
> wooledg:~$ ls -ld file
> -rw-r--r-- 1 wooledg 563 24 Jul  2  2015 file
> wooledg:~$ cat file
> line one
> line two
> match
> wooledg:~$ ln -s file slink
> wooledg:~$ ls -ld slink
> lrwxrwxrwx 1 wooledg wooledg 4 Jun  6 08:18 slink -> file
> wooledg:~$ cat slink
> line one
> line two
> match
>
> Now, if I rename "file", the symlink "slink" will no longer point to
> the right place:
>
> wooledg:~$ mv file xfile
> wooledg:~$ cat slink
> cat: slink: No such file or directory
>
> I believe that's what you already knew before asking this question,
> but I had to include this information to be sure, because you didn't
> actually say what you had already tried.
>
> Now, the other type of link is older and much more subtle.  Hard links
> work at the inode level.  To really understand what a hard link is, you
> need to understand how directories and inodes work in Unix.
>
> A directory in Unix is (conceptually) just a list of filenames and
> inode numbers.  Imagine a telephone book.  You can look up a person's
> name, and next to their name is their telephone number.  This is how
> Unix directories work.  This is where the name "directory" actually
> comes from.  (Phone books are formally called "directories".)
>
> (If you're too young to know what a phone book is... then I don't know
> how to help you with that.)
>
> So.  You have a directory, and inside the directory is a file.  Let's
> revert back to our original state:
>
> wooledg:~$ rm slink; mv xfile file
> wooledg:~$ ls -ld file
> -rw-r--r-- 1 wooledg 563 24 Jul  2  2015 file
>
> Now let's create a "hard" link to the file:
>
> wooledg:~$ ln file hlink
> wooledg:~$ ls -ld file hlink
> -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 file
> -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 hlink
>
> See the "2" between the permissions and the owner?  That's the link
> count.  That tells us how many hard links there are to the file.  If
> we inspect the inode numbers for these two directory entries, we'll
> see that they are the same:
>
> wooledg:~$ ls -li file hlink
> 1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 file
> 1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 hlink
>
> Same inode number.  They are in fact two different names for the same
> *file*.  Both directory entries contain the same inode number, which
> is the only thing a directory can tell you.
>
> Now, if I rename the file, let's observe what happens:
>
> wooledg:~$ mv file xfile
> wooledg:~$ ls -li xfile hlink
> 1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 hlink
> 1573283 -rw-r--r-- 2 wooledg 563 24 Jul  2  2015 xfile
> wooledg:~$ cat hlink
> line one
> line two
> match
>
> In this case, the renaming of *one* of the hard links did not matter.
> The *other* hard link still "points to" the inode that contains the
> actual contents.  You can move the hard link ("file") to a subdirectory,
> or any other directory inside the file system, and it won't matter.
> The hard links still point to the same inode number.
>
> Now, this part is very important: inode numbers are only meaningful
> within a single file system.  If you move one of the "files" *outside*
> of this file system, then the hard links will no longer reference 
> the same file.  If you modify one of them, the other will still contain
> a copy of the original content.
>
> wooledg:~$ mkdir /run/user/1000/tmp
> wooledg:~$ mv xfile file
> wooledg:~$ mv hlink /run/user/1000/tmp
> wooledg:~$ ls -lid file /run/user/1000/tmp/hlink
> 1573283 -rw-r--r-- 1 wooledg     563 24 Jul  2  2015 file
>  319746 -rw-r--r-- 1 wooledg wooledg 24 Jul  2  2015 /run/user/1000/tmp/hlink
> wooledg:~$ echo "another line" >> /run/user/1000/tmp/hlink
> wooledg:~$ cat file
> line one
> line two
> match
>
> At this point, even though the two "files" were orignally hard linked,
> that changed when we moved one of them to a different file system.
> Now they are simply two files with no relationship to each other.
>
> So... to answer your question, as long as you only have *ONE* file
> system to worry about, you can make hard links, and I believe they
> will satisfy your stated requirements.


Thanks indeed to Greg for his complete explanation and to all who provided
help...  Yes, hardlink should be the case for what I'm looking for...  But, I
also need that, when renaming the target file, the link would automatically
change its name so that it keeps equal to the target's name...  Is this
possibile?

Thanks, kind regards

Rodolfo

[toc] | [prev] | [next] | [standalone]

#181840

On Tue, Jun 06, 2017 at 06:41:03PM +0100, Rodolfo Medina wrote:
> But, I
> also need that, when renaming the target file, the link would automatically
> change its name so that it keeps equal to the target's name...  Is this
> possibile?

No.  Not without exhaustively searching the file system to find the
other links and rename them, and that would have to be something you
do manually, *not* automatically triggered by a rename.

What are you actually trying to do?

[toc] | [prev] | [next] | [standalone]

#181842

Greg Wooledge <wooledg@eeg.ccf.org> writes:

> On Tue, Jun 06, 2017 at 06:41:03PM +0100, Rodolfo Medina wrote:
>> But, I
>> also need that, when renaming the target file, the link would automatically
>> change its name so that it keeps equal to the target's name...  Is this
>> possibile?
>
> No.  Not without exhaustively searching the file system to find the
> other links and rename them, and that would have to be something you
> do manually, *not* automatically triggered by a rename.
>
> What are you actually trying to do?

I'm making a musical mp3s library.  So I have, say, the following directory
tree:

+ musical-library
  | 
  + genres
  | |
  | + classical
  | |
  | + pop
  | |
  | + folk
  | |
  | + opera: una.furtiva.lacrima-schipa.mp3
  |
  |          casta.diva-callas.mp3
  |
  + artists
    |
    + tito-schipa
    |
    + maria-callas
    |
    + frank-sinatra

etc.  Now, suppose that I want to put una.furtiva.lacrima-schipa.mp3 *also* in
the tito-schipa directory, and casta.diva-callas.mp3 *also* in the maria-callas
directory...  That's what I'm trying to do...

Thanks,

Rodolfo

[toc] | [prev] | [next] | [standalone]

#181843

On Tue, 6 Jun 2017, Rodolfo Medina wrote:
> Greg Wooledge <wooledg@eeg.ccf.org> writes:
>
>> On Tue, Jun 06, 2017 at 06:41:03PM +0100, Rodolfo Medina wrote:
>>> But, I
>>> also need that, when renaming the target file, the link would automatically
>>> change its name so that it keeps equal to the target's name...  Is this
>>> possibile?

Totally possible. Write a library of functions with functions that
simultaneously

   1. perform the hard link manipulations you need

   2. update a database that tracks, for each media file, its
      linked-locations.

Then just use your new functions to manipulate your a/v media files.

Problem solved.

>> No.  Not without exhaustively searching the file system to find the
>> other links and rename them, and that would have to be something you
>> do manually, *not* automatically triggered by a rename.
>>
>> What are you actually trying to do?
>
> I'm making a musical mp3s library.  So I have, say, the following directory
> tree:

[toc] | [prev] | [next] | [standalone]

#181848

On Tue, 6 Jun 2017, davidson@freevolt.org wrote:

> On Tue, 6 Jun 2017, Rodolfo Medina wrote:
>> Greg Wooledge <wooledg@eeg.ccf.org> writes:
>> 
>>> On Tue, Jun 06, 2017 at 06:41:03PM +0100, Rodolfo Medina wrote:
>>>> But, I
>>>> also need that, when renaming the target file, the link would 
>>>> automatically
>>>> change its name so that it keeps equal to the target's name...  Is this
>>>> possibile?
>
> Totally possible. Write a library of functions with functions that
> simultaneously
>
>  1. perform the hard link manipulations you need
>
>  2. update a database that tracks, for each media file, its
>     linked-locations.
>
> Then just use your new functions to manipulate your a/v media files.

Clarification/correction to above sentence: It's the *links* your
functions would primarily manipulate. not the files.

> Problem solved.

(Apologies for sounding so glib. In my defense, I was celebrating a
little, because I realised that I too might like to have the same
functionality OP has described, and it looks not difficult to
implement.)

>
>>> No.  Not without exhaustively searching the file system to find the
>>> other links and rename them, and that would have to be something you
>>> do manually, *not* automatically triggered by a rename.
>>> 
>>> What are you actually trying to do?
>> 
>> I'm making a musical mp3s library.  So I have, say, the following directory
>> tree:
>
>

[toc] | [prev] | [next] | [standalone]

#181876

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jun 06, 2017 at 07:15:25PM +0100, Rodolfo Medina wrote:
>Greg Wooledge <wooledg@eeg.ccf.org> writes:
>
>> On Tue, Jun 06, 2017 at 06:41:03PM +0100, Rodolfo Medina wrote:
>>> But, I
>>> also need that, when renaming the target file, the link would automatically
>>> change its name so that it keeps equal to the target's name...  Is this
>>> possibile?
>>
>> No.  Not without exhaustively searching the file system to find the
>> other links and rename them, and that would have to be something you
>> do manually, *not* automatically triggered by a rename.
>>
>> What are you actually trying to do?
>
>I'm making a musical mp3s library.  So I have, say, the following directory
>tree:
>
>+ musical-library
>  |
>  + genres
>  | |
>  | + classical
>  | |
>  | + pop
>  | |
>  | + folk
>  | |
>  | + opera: una.furtiva.lacrima-schipa.mp3
>  |
>  |          casta.diva-callas.mp3
>  |
>  + artists
>    |
>    + tito-schipa
>    |
>    + maria-callas
>    |
>    + frank-sinatra
>
>etc.  Now, suppose that I want to put una.furtiva.lacrima-schipa.mp3 *also* in
>the tito-schipa directory, and casta.diva-callas.mp3 *also* in the maria-callas
>directory...  That's what I'm trying to do...

I've wanted to do something like that in the past, myself. The solution
I was considering (though I never actually got around to implementing
it) was a FUSE-based filesystem. The idea would be that files would be
stored in, say, a hidden, top-level directory and their ID3 tags
scanned. The filesystem would then make the files available in, say
"by-genre", "by-artist", "by-title", "by-album" and so on folders.
Possibly with the ability to have multiple layers so you can get 
"by-artist/Queen/by-album/Greatest Hits II/*.mp3"

In other words, listing a directory would provide a live filtering of
that available files, depending on the directory name. In an ideal
world, changing the filename/path would alter the ID3 tags and vice
versa.


-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#182197

On Wed, Jun 07, 2017 at 12:19:11PM +0100, Darac Marjal wrote:
> On Tue, Jun 06, 2017 at 07:15:25PM +0100, Rodolfo Medina wrote:
> > Greg Wooledge <wooledg@eeg.ccf.org> writes:
> > 
> > > On Tue, Jun 06, 2017 at 06:41:03PM +0100, Rodolfo Medina wrote:
> > > What are you actually trying to do?
> > 
> > I'm making a musical mp3s library.  So I have, say, the following directory
> > tree:
> > 
> > + musical-library
> >  |
> >  + genres
> >  | |
> >  | + classical
> >  | |
> >  | + pop
> >  | |
> >  | + folk
> >  | |
> >  | + opera: una.furtiva.lacrima-schipa.mp3
> >  |
> >  |          casta.diva-callas.mp3
> >  |
> >  + artists
> >    |
> >    + tito-schipa
> >    |
> >    + maria-callas
> >    |
> >    + frank-sinatra
> > 
> > etc.  Now, suppose that I want to put una.furtiva.lacrima-schipa.mp3 *also* in
> > the tito-schipa directory, and casta.diva-callas.mp3 *also* in the maria-callas
> > directory...  That's what I'm trying to do...
> 
> I've wanted to do something like that in the past, myself. The solution
> I was considering (though I never actually got around to implementing
> it) was a FUSE-based filesystem. The idea would be that files would be
> stored in, say, a hidden, top-level directory and their ID3 tags
> scanned. The filesystem would then make the files available in, say
> "by-genre", "by-artist", "by-title", "by-album" and so on folders.
> Possibly with the ability to have multiple layers so you can get
> "by-artist/Queen/by-album/Greatest Hits II/*.mp3"
> 
> In other words, listing a directory would provide a live filtering of
> that available files, depending on the directory name. In an ideal
> world, changing the filename/path would alter the ID3 tags and vice
> versa.

pytagsfs is such a FUSE fs; it's packaged in testing now.

-dsr-

[toc] | [prev] | [next] | [standalone]

#181845

On Tue 06 Jun 2017 at 18:41:03 (+0100), Rodolfo Medina wrote:

> Thanks indeed to Greg for his complete explanation and to all who provided
> help...  Yes, hardlink should be the case for what I'm looking for...  But, I
> also need that, when renaming the target file, the link would automatically
> change its name so that it keeps equal to the target's name...  Is this
> possibile?

Please be aware there _is no_ target name. All the hardlinks to
a file have the same status.

As for renaming (IIUC) if you want to rename all the file entries
together, you can pick up any instance's inode with ls, then use
find <mount-point> -inum <num>
to find all the other instances in the filesystem. Naturally,
do this in a script.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#181847

On Ter, 06 Jun 2017, David Wright wrote:
> As for renaming (IIUC) if you want to rename all the file entries
> together, you can pick up any instance's inode with ls, then use
> find <mount-point> -inum <num>
> to find all the other instances in the filesystem.

Or use the -samefile option of find and do that in one step.
-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [next] | [standalone]

#181853

Eduardo M KALINOWSKI <eduardo@kalinowski.com.br> writes:

> On Ter, 06 Jun 2017, David Wright wrote:
>> As for renaming (IIUC) if you want to rename all the file entries
>> together, you can pick up any instance's inode with ls, then use
>> find <mount-point> -inum <num>
>> to find all the other instances in the filesystem.
>
> Or use the -samefile option of find and do that in one step.


Thanks to all.  That was very useful.  With `find -samefile' I find at once all
the occurrence of that file.  Then I have to rename them one to one, though...
But it's all right.

Rodolfo

[toc] | [prev] | [next] | [standalone]

#181846

On Ter, 06 Jun 2017, Rodolfo Medina wrote:
> But, I
> also need that, when renaming the target file, the link would automatically
> change its name so that it keeps equal to the target's name...  Is this
> possibile?

Not directly. It is possible if you have something monitoring the  
filesystem for changes. Search for inotify.

-- 
Eduardo M KALINOWSKI
eduardo@kalinowski.com.br

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web