Martin Lorenz <mar...@lorenz.priv.at> writes: >r...@vs152058:~# ( >> env -i >> date -R > testfile1 >> ls -ldog testfile1 >> echo >> rm -f testfile2 >> echo >> cp testfile1 testfile2 >> ls -ldog testfile2 >> ) >- -r-Sr-x--- 1 32 30. Dez 20:22 testfile1
This is really wierd. Your testfile1 should not have been created with these permissions. I dont know what would cause this apart from bugs or some sort of corruption. >stat64("testfile1", {st_dev=makedev(144, 109), st_ino=37590572, >st_mode=S_IFREG|S_ISUID|0450, st_nlink=1, st_uid=0, st_gid=0, >st_blksize=4096, st_blocks=8, st_size=32, st_atime=2010/12/30-20:22:29, >st_mtime=2010/12/30-20:22:29, st_ctime=2010/12/30-20:22:29}) = 0 >stat64("testfile2", 0xbfffd624) = -1 ENOENT (No such file or >directory) >open("testfile1", O_RDONLY|O_LARGEFILE) = 3 >open("testfile2", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0) = 4 >does this tell you something? It tells me why your testfile2 has zero permissions - because cp(1) created it that way. The third argument to open(2) when used with O_CREAT is the permissions to use on the new file (the kernel will apply the umask). cp(1) should have used a value of 0450 for that (since it uses the source file permissions). I don't know why it used 0. I'm sorry that I can't provide any answers. Maybe by pointing out these anomalies, someone else may see what is wrong. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51f.4d1e8489.ba...@getafix.xdna.net