[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Drag and Drop Up-One-Level
From:       Stian =?iso-8859-1?Q?S=F8iland?= <stian () soiland ! no>
Date:       2004-05-08 17:23:48
Message-ID: 20040508172348.GN9150 () itea ! ntnu ! no
[Download RAW message or body]

On 2004-05-07 21:44:01, Gustavo Sverzut Barbieri wrote:

> > (therefor, if you have created two dirs, with hard-linked
> > files, it could be possible to see that files in both dirs are
> > hardlinked - and therefore that they MIGHT be the same files - avoiding
> > editing a file that should have been a copy)
> ???

Ok, I'll try to make it clearer. Just like ls -l prints the reference
count, files that have several names should have that indicated in some
way:

  Dir 1:

  [    ] file1.txt
  [   2] file2.txt
  [    ] file3.txt


  Dir 2:

  [    ] file1.txt
  [   2] file2.txt
  [    ] file4.txt
  [   2] file5.txt

[   ] should be thought of as the normal TXT icon. For files that are
hard linked, the reference count could be superimposed onto the icon.
This indicates that this file doesn't only appear in this directory.

This could be important if you need 700 MB diskspace, and you try to
delete your redhat73.iso - but nothing happens since it's also hard
linked somewhere else. (There's no easy way to backreference those other
file names without searching the whole volume. That could be an option
from the "Preferences"-dialog, though.)

Another issue is when a skilled user (but not yet an expert user) is
learning about this hard linking-stuff, and he needs to know the
difference between copying and linking. 

If he drags a file somewhere with "linking" - and then afterwards both
files changes icon - it would be easier for him to understand that what
he did affected both files, and that he hasn't created a symbolic link.


One issue is if displaying the number is really useful. Most files with
more than 1 link (except directories) would have 2 links. More links are
less common. User's might expect that the two files are different, that
one is #1 and the other #2, specially when only one of them are present.
They would then search all over for #1 with no luck.

Some other nice icon could of course be used in the superimposing. I
don't know what would be appropriate. It would be very important to
differenciate it from a symbolic link. If people mess up hardlinks and
symbolic links, bad things could happen. 

Symbolic links are in many ways 'weaker' - you cannot delete the
original file and keep the linked version. You cannot move around on the
original file - or the linked one if it's relative. On the other hand -
symbolic links work crossdevice, so you could have a symlink to a shared
resource from your home directory.

(in my opinion, symbolic links are best for directories, hard links for
files. Hard linked directories are usually not possible without deep
hacking.)


> AND, konqueror as a File Manager should provide every possible way to manage 
> files. If the problem is instructing users, put it in the docs, KTips and 
> tooltips. 
> 	It's really strange you can zip, encrypt and do thousand of 
> non-file-management stuff using konqueror but cannot create a simple 
> hardlink.

I agree that it should be possible to create hardlinks - as an option.
Maybe it needs to be called something else since most common users don't
understand that ALL file names are links to the inode - that again have
the metadata and links to the actual file contents. People feel that
when they save a file in a directory - that's where it IS.

Maybe "Add another filename (hardlink)" or something like that?

-- 
Stian Søiland               Work toward win-win situation. Win-lose
Trondheim, Norway           is where you win and the other lose.
http://www.soiland.no/      Lose-lose and lose-win are left as an
                            exercise to the reader.  [Limoncelli/Hogan]
                            Og dette er en ekstra linje 
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]