MacPorts duplicate files or hardlinks?

[Ryan Schmidt]

On May 24, 2009, at 17:45, Scott Haneda wrote:

> * Glad I replied to this one, there is a lot of odd stuff going on  
> I can not explain, hope someone where more knowledgeable about the  
> phases can explain...
>
> According to the man page, that 2 is for directories.  I do not  
> think it has any bearing on the type of file it is. It is a count  
> of some form.
>
> Below is some testing I did.  If you are going to delete, I would  
> recurse, run `file` on the item, make sure it is a link, and then  
> delete. I do not think you should delete them that way though.

Do not delete either reference to the file. They are both supposed to  
be there. They are hardlinks to the same file, and as such, the file  
only exists on disk once, and only occupies disk space once. You  
won't free any disk space by removing either reference, but you will  
break your MacPorts installation by doing so. MacPorts wants to  
manage these links for you, through the port activate/deactivate  
commands. You will only free disk space by removing both references,  
but again you should let MacPorts manage that for you through the  
port uninstall command.


> I think this would be a good thread to look at:
> http://www.nabble.com/%22Reclaiming-disk-space%22-documentation- 
> guide-missing-td23686542.html
>
> I just ran `$sudo port distfiles all`, very chatty results.

Yes. The "port distfiles" command was added somewhat recently. For  
each distfile the port requests, it prints every URL it knows about  
where that file can be downloaded. It was to be used as part of the  
distfiles.macports.org setup, but that ended up being done in a  
different way, so the command now serves no particular purpose and  
might be removed. Out of curiosity, what did you want to find out by  
running "port distfiles all"? It would print the URL of every  
distfile of every port, which I'm guessing is not what you needed.


> I did try to run this, according to that thread:
> $sudo port clean --distfiles all
> Error: clean does not accept --distfiles

Sorry, I never use that myself (I tend to use --all) and I recited it  
from memory and got it wrong. The correct command would be:

sudo port clean --dist all


> Then I tried
> sudo port clean --all all
> which worked a little, but got hung on..
>
> couldn't change working directory to "/opt/local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_sysut 
> ils_am-utils/work": no such file or directory
>     while executing
> "cd $savedir"
>     (procedure "foreachport" line 17)
>     invoked from within
> "foreachport $portlist {
>         set target $action
>
>         # If we have a url, use that, since it's most specific
>         # otherwise try to map the ..."
>     (procedure "action_target" line 7)
>     invoked from within
> "$action_proc $action $portlist [array get global_options]"
>     (procedure "process_cmd" line 86)
>     invoked from within
> "process_cmd $remaining_args"
>     invoked from within
> "if { [llength $remaining_args] > 0 } {
>
>     # If there are remaining arguments, process those as a command
>
>     # Exit immediately, by default, unless..."
>     (file "/opt/local/bin/port" line 3247)
> pwd: error retrieving current directory: getcwd: cannot access  
> parent directories: No such file or directory

I assume you were in the directory /opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync.macports.org_release_ports_sysutil 
s_am-utils/work when you ran the command "sudo port clean --all all",  
which deleted that directory, and then MacPorts got confused when it  
tried to put you back in that now-nonexistent directory when it was  
done. The error message is harmless.

http://trac.macports.org/ticket/17076

http://lists.macosforge.org/pipermail/macports-users/2009-May/ 
015261.html

http://lists.macosforge.org/pipermail/macports-users/2007-May/ 
003344.html


> Now `sudo port distfiles all` is broken.

In what way?


> For what is is worth, here are the tests I did to make sure  
> deleting the hard links would not hurt outside of ports, within  
> ports, no idea.
> I just did this test:

Yes, the below does show how hardlinks work.

> # Make a file on the Desktop
> $touch ~/Desktop/original_file
>
> # Show where I am in the shell, in this case, test dir on desktop
> $pwd
> /Users/me/Desktop/test
>
> # link to the file in the desktop from the test dir I am sitting in
> $ln ~/Desktop/original_file linked_file
>
> # Show the result of the link I just made:
> $ls -la
> total 8
> drwxr-xr-x   3 haneda  staff  102 May 24 15:24 .
> drwx------+ 11 haneda  staff  374 May 24 15:23 ..
> -rw-r--r--   2 haneda  staff   21 May 24 15:24 linked_file

Note the "2" in the line for linked_file, indicating that 2 filenames  
are linked to this one file on disk.

> # Put some data into the original_file
> $echo 'this is the original' >> ~/Desktop/original_file
>
> # Check of the link worked by reading the link
> $cat linked_file
> this is the original
>
> # Both files show 21 bytes, but use `file` to see what it is
> $file linked_file
> linked_file: ASCII English text
>
> # Compared to the other file
> $file ~/Desktop/original_file
> /Users/me/Desktop/original_file: ASCII English text
>
> # Delete the link
> $rm linked_file
>
> # make sure the original is still there
> $ls -la ~/Desktop/ | grep original
> -rw-r--r--   1 haneda  staff     21 May 24 15:24 original_file

Note the "1" in the line, showing now only a single filename points  
to this file on disk.