headers
robert ethridge | 10 Feb 01:17
Picon
Gravatar

bug#10774: runcon'|

what does this do (...'|....) in relation to runcon?
--

-- 
Mr. Ethridge.Robert
Permalink | Reply | 1 comment |
headers
Gerrie Myburgh | 9 Feb 05:41

bug#10769: uniq

Hi,

There seems to be a bug in uniq. To duplicate:

Use attached file and  run it through uniq with -d. It then gives no
output. If uniq is run without a flag then the original file is output
from uniq.

Gerrie <at> GerrieM /cygdrive/c/adhoc/vodacom

$ uniq -d a.txt

Gerrie <at> GerrieM /cygdrive/c/adhoc/vodacom

Gerrie <at> GerrieM /cygdrive/c/adhoc/vodacom

$ uniq a.txt

084699880820120120100749

084800053520120120100741

084800053520120120100741

Gerrie <at> GerrieM /cygdrive/c/adhoc/vodacom

$ uniq --version

uniq (GNU coreutils) 8.10
(Continue reading)

Permalink | Reply | 2 comments |
headers
Filipus Klutiero | 7 Feb 21:10
Picon

bug#10755: stat: Please add directive to display size on disk

The other day I tried figuring out how much disk space a small file 
took. I used stat, but I only realized today that stat does not provide 
that information directly, as explained by Eric Blake and Pádraig Brady 
in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10561

This information is provided indirectly by %b and %B. Multiplying the 2 
should give the size on disk. Example:

stat -c 'allocated-space=%B*%b apparent-size=%s' $file

Currently, this information can be obtained from du:

$ stat -c '%s' /etc/phpmyadmin/htpasswd.setup
54
chealer <at> vinci:~$ du -h /etc/phpmyadmin/htpasswd.setup
4,0K    /etc/phpmyadmin/htpasswd.setup
chealer <at> vinci:~$

However, it would be quite useful if stat could be used to display 
simultaneously a file's real size and size on disk.

Eric Blake suggested this directive to be %S. For the description, he 
suggested:

%S  Allocated size (same as %b * %B)

I would like to aim for clarity, as these various statistics can be 
confusing. I suggest to use the name "Size on disk". I also suggested 
the following:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernhard Voelker | 7 Feb 13:26
Picon

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing


On 02/07/2012 11:45 AM, Michael Felt wrote:
> Just reading - for reference only - AIX 5.3, and I expect new versions behave as follows
> (second link becomes a hardlink to original file, mv "removes" one hard link, i.e. original file (as
inode) remains.
> 
> root <at> x105:[/tmp/test]touch f
> root <at> x105:[/tmp/test]ln -s f l
> root <at> x105:[/tmp/test]ls -l
> total 0
> -rw-r--r--  1 root system 0 2012-02-07 11:41 f
> lrwxrwxrwx  1 root system 1 2012-02-07 11:41 l -> f
> root <at> x105:[/tmp/test]ln l s
> root <at> x105:[/tmp/test]ls -ogi
> total 0
> 239 -rw-r--r--  2 0 2012-02-07 11:41 f
> 240 lrwxrwxrwx  1 1 2012-02-07 11:41 l -> f
> 239 -rw-r--r--  2 0 2012-02-07 11:41 s
> root <at> x105:[/tmp/test]mv s f
> root <at> x105:[/tmp/test]ls -ogi
> total 0
> 239 -rw-r--r--  1 0 2012-02-07 11:41 f
> 240 lrwxrwxrwx  1 1 2012-02-07 11:41 l -> f

Hi Michael,

the result is the same, but there's a little difference here:
your ln does not create a hardlink to the symlink, but
rather a hardlink to the symlink's *target*.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Proulx | 6 Feb 22:34
Favicon
Gravatar

bug#10735: chmod +x

francky.leyn <at> telenet.be wrote:
> some more questions.
> I abstract a file system as something where each dir/file has a header
> where all properties reside.

Yes.  This information is stored in the Inode.  You can read about it here.

  http://en.wikipedia.org/wiki/Inode

> There doesn't exist a hybrid file system that unites eg. NTFS and ext4?

No.  Not as far as I know.

> NTFS is not POSIX complient?

No.  At least as far as I know.  Others will know.  I don't use NTFS.
In any case it would need to support Unix filesystem permissions along
with user and group ownership and the full set of behavior.

Until recently it was only possible to reliably read from NTFS because
the necessary information for it wasn't reverse engineered yet.
Recently this has been completed and it is now possible to write to
NTFS.  Given how it came about it is amazing that it works at all.

Bob
Permalink | Reply | 0 comments |
headers
Bob Proulx | 6 Feb 21:33
Favicon
Gravatar

bug#10735: chmod +x

Francky Leyn wrote:
> Dear Bob, 
> 
> thanks for your intervention. 
> The problem is a lot clearer to me right now. 
> 
> It is indead a Virtual Box on top of Windows 7 with an NTFS system 
> and the Linux virtual box is Ubuntu 11.04. 

NTFS doesn't have any concept of the same file modes as a Unix-like
filesystem.  Therefore any adaption layer sitting between an NTFS
layer and a Unix filesystem layer can only make compromises.  It can't
do what it can't do.  For example, where would it store this
information?  What would NTFS do with it?

> My conclusion is the following: if I want to execute chmod +x properly, 
> I need an ext (4?) partition on my machine, separated from the Windows 7 
> NTFS system. Correct? 

Yes.  It doesn't need to be ext2, ext3, ext4.  It could be any POSIX
compliant filesystem.  That would include xfs, jfs, for example along
with many others.

If the files are stored on NTFS then NTFS can't do it.  If you want
Unix filesystem semantics then it must be on a unix filessystem.  For
example on the VirtualBox filesystem.  If you chmod files in /tmp in
the virtual machine everything works fine because that is using a real
unix filesystem.

I am sure that you thought that disk space was disk space and that you
(Continue reading)

Permalink | Reply | 0 comments |
headers
francky.leyn | 6 Feb 15:23
Picon
Favicon
Gravatar

bug#10735: chmod +x file


Hello, 

I perform the following: 

ubuntu <at> ubuntu-VirtualBox:~/.gvfs/account on stockholm/Documents/03
professional/structured_documentation$ ls -l doc/filters_for_this_document 
-rwx------ 1 ubuntu ubuntu 98 2012-02-06 14:47 doc/filters_for_this_document 
ubuntu <at> ubuntu-VirtualBox:~/.gvfs/account on stockholm/Documents/03
professional/structured_documentation$ whoami 
ubuntu 
ubuntu <at> ubuntu-VirtualBox:~/.gvfs/account on stockholm/Documents/03
professional/structured_documentation$ chmod +x doc/filters_for_this_document 
chmod: changing permissions of `doc/filters_for_this_document': Operation not supported 
ubuntu <at> ubuntu-VirtualBox:~/.gvfs/account on stockholm/Documents/03
professional/structured_documentation$ chmod --version 
chmod (GNU coreutils) 8.5 

On another machine I have version 6.10, and there I don't get 
the error "Operation not supported". 

What is wrong here? 

Best regards, 

Francky Leyn
Permalink | Reply | 9 comments |
headers
Wang, YuanTao | 2 Feb 09:25
Picon
Favicon
Gravatar

bug#10699: bug of `date`: why 1/1/2012 is the second week of 2012?

$ date -d "2012-01-01 00:00:00" +%U
01

but in "man date"
%U     week number of year, with Sunday as first day of week (00..53)

Is it a bug?

$ uname -r
2.6.18-128.1.6.el5xen
Permalink | Reply | 1 comment |
headers
Bernhard Voelker | 1 Feb 12:43
Picon

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

On 02/01/2012 09:21 AM, Bernhard Voelker wrote:

>   $ touch f && ln -s f l && ln l s && ls -ogi
>   total 0
>   6444 -rw-r--r-- 1 0 Feb  1 08:52 f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
>   6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f
> 
> Trying to mv the hardlink over the symlink seems to succeed:
> 
>   $ ~/git/coreutils/src/mv s l
> 
> ... but the name 's' was not unlinked:

...

> That behaviour didn't change at least since version 7.1
> (on openSuSE-11.3), but back in the earlier days in 5.93
> (SLES-10.3), 's' disappeared as expected:

Hmm, looks like commit
   f1d1ee91217d08527c6bf7682987339e38116268
introduced this in 2006.

Have a nice day,
Berny
Permalink | Reply | 0 comments |
headers
Bernhard Voelker | 1 Feb 09:21
Picon

bug#10686: mv: moving hardlink of a softlink to the softlink does nothing

Playing around with the latest mv checkin,
I noticed another corner case:

Create a file 'f', a symlink 'l' to it, and
then a hardlink 's' to that symlink:

  $ touch f && ln -s f l && ln l s && ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Trying to mv the hardlink over the symlink seems to succeed:

  $ ~/git/coreutils/src/mv s l

... but the name 's' was not unlinked:

  $ ls -ogi
  total 0
  6444 -rw-r--r-- 1 0 Feb  1 08:52 f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 l -> f
  6462 lrwxrwxrwx 2 1 Feb  1 08:52 s -> f

Using the -v option looks also normal, but is a nop:

  $ ~/git/coreutils/src/mv -v s l
  ‘s’ -> ‘l’
  $ ls -ogi
  total 0
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jim Meyering | 31 Jan 13:33

bug#10679: mv --backup=numbered should perform an atomic update

Since I'm closing the related ticket in which this was raised,
here's a new one:

In http://bugs.gnu.org/6960, Anders Kaseorg noted that
'mv --backup=numbered ...' does not perform an atomic update.
It should.
Permalink | Reply | 0 comments |

Gmane