Re: recent gnulib changes require coreutils adaptations
Jim Meyering <[EMAIL PROTECTED]> writes:
> I've tested the following versions of git:
>
> 1.5.3.rc1.27.ga5e40
> 1.5.2.4
> 1.4.4.4
Very strange. I'm using Debian stable git (1.4.4.4).
> E.g., from a git-cloned coreutils work area,
> "git-rm -n doc/.gitignore" should exit successfully.
> Does that work for you?
Yes. Here's the strace output for that, if it helps.
Maybe you have a $HOME/.gitconfig file? I don't.
... [omitting shared library stuff]
getcwd("/home/eggert/src/gnu/cu-gnulib", 4097) = 31
access(".git/refs/", X_OK) = 0
access(".git/objects/", X_OK) = 0
lstat64(".git/HEAD", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
open(".git/HEAD", O_RDONLY) = 3
read(3, "ref: refs/heads/master\n", 255) = 23
close(3)= 0
brk(0) = 0x80df000
brk(0x810) = 0x810
access("/home/eggert/.gitconfig", R_OK) = -1 ENOENT (No such file or directory)
open(".git/config", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=53, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f92000
read(3, "[core]\n\trepositoryformatversion "..., 4096) = 53
read(3, "", 4096) = 0
close(3)= 0
munmap(0xb7f92000, 4096)= 0
access("/home/eggert/.gitconfig", R_OK) = -1 ENOENT (No such file or directory)
open(".git/config", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=53, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f92000
read(3, "[core]\n\trepositoryformatversion "..., 4096) = 53
read(3, "", 4096) = 0
close(3)= 0
munmap(0xb7f92000, 4096)= 0
open(".git/index.lock", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
rt_sigaction(SIGINT, {0x8076010, [INT], SA_RESTART}, {SIG_DFL}, 8) = 0
open(".git/index", O_RDONLY)= 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=78416, ...}) = 0
mmap2(NULL, 78416, PROT_READ|PROT_WRITE, MAP_PRIVATE, 4, 0) = 0xb7e2a000
close(4)= 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f92000
write(1, "rm \'doc/.gitignore\'\n", 20) = 20
unlink(".git/index.lock") = 0
munmap(0xb7f92000, 4096)= 0
exit_group(0) = ?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df reporting and removing files (Re: (no subject))
Elmian Shabahang scripsit: > as I get , some processes are still blocking the file. How can I find and > kill them? There is no portable way. However, if your system provides the "lsof" command, you can use that to discover the files currently open and the processes that hold them open. -- John Cowan [EMAIL PROTECTED] "Mr. Lane, if you ever wish anything that I can do, all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything, you can put the telegram down as a forgery." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
RE: df reporting and removing files (Re: (no subject))
Hello , Thanks for your complete and helpful explanation. I would be thankful if you could help me with following question. as I get , some processes are still blocking the file. How can I find and kill them? Best regards, Elmian, -Original Message- From: Bob Proulx [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 17, 2007 8:01 PM To: Elmian Shabahang Cc: bug-coreutils@gnu.org Subject: df reporting and removing files (Re: (no subject)) Elmian Shabahang wrote: > Hello, In the future please include a meaningful subject line otherwise it is likely that your message will be deleted without reading because it looks too much like spam. > Please find following information: > /dev/vg00/lvol8 8.7G 7.7G 619M 93% /u01 > > [EMAIL PROTECTED] u01]$ du -lkhs /u01 > 5.5G/u01 You appear to be concerned that df reports 7.7G used but du does not find it by traversing the filesystem? Is that correct? > Note that I have deleted a 2.2 GB file , and du don't update the output > table. That is perfectly okay. The 'df' command reports information about filesystem. The 'du' command traverses directories and reports information in directory hierarchies. Those are two different things and they may report different information. In this case it means that disk space is in use by processes but is not reachable by the directory hierarchy. Since you said that you removed the file from the directory this information is verified. The filesystem recovers disk space through garbage collection. When files are busy the disk space is in use. When the reference count for a file is reduced to zero then the filesystem recovers the disk blocks associated with the file. Removing files removes the directory pointer to that file but it does not remove the file from use by running processes. If a running process has the file open then the reference count will be non-zero due to use by that process and the filesystem will not be able to reclaim that disk space until the process exits. A typical example is a program writing a log file. The log file may grow to be quite large. As long as the process is running the reference count for that file will be non-zero. Removing the file from the directory will not free up the disk space. In fact doing so means that there is no no way to access that file again. The only way to reduce the reference count would be to kill the process that holds the file in use. To avoid this case it is better to truncate large files to free up the disk space immediately instead of removing them. Hope that helps. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
