I have a large jazz CD collection, a lot of which may not be available forever. I'm concerned with things I've read that CDs and DVDs may be subject to deterioration. I also know that CDs can also be damaged by scratches, etc. I'm familiar with and have successfully used the CD cloning utility of k3b to create a playable (with a standard CD player) duplicate CD, but I want to copy the entire image to my hard drive, so I can keep it there in case the original becomes unplayable later. I have no interest in creating a bunch of duplicate CDs, most of which will never be used in my lifetime. When I clone directly to my hard drive, the program created two files: k3b_0.img and k3b_0.img.toc. This is fine, but I can't figure out how to write this image to another CD. I've read the documentation that comes with the program without success. -- "Just once, I wish we would encounter an alien menace that wasn't immune to bullets" -- The Brigader, "Dr. Who" -- We cannot put the face of a person on a stamp unless said person is deceased. My suggestion, therefore, is that you drop dead. -- James E. Day, Postmaster General
On 9/12/05, Tim Hanson <tjhanson98@comcast.net> wrote:
I have a large jazz CD collection, a lot of which may not be available forever. I'm concerned with things I've read that CDs and DVDs may be subject to deterioration. I also know that CDs can also be damaged by scratches, etc.
I'm familiar with and have successfully used the CD cloning utility of k3b to create a playable (with a standard CD player) duplicate CD, but I want to copy the entire image to my hard drive, so I can keep it there in case the original becomes unplayable later. I have no interest in creating a bunch of duplicate CDs, most of which will never be used in my lifetime.
When I clone directly to my hard drive, the program created two files: k3b_0.img and k3b_0.img.toc. This is fine, but I can't figure out how to write this image to another CD. I've read the documentation that comes with the program without success.
-- "Just once, I wish we would encounter an alien menace that wasn't immune to bullets" -- The Brigader, "Dr. Who"
-- We cannot put the face of a person on a stamp unless said person is deceased. My suggestion, therefore, is that you drop dead. -- James E. Day, Postmaster General
What I do is to encode my CDs with FLAC. It does not lose any quality, and saves like half of the space. Later you can create a CD from the files. -- Svetoslav Milenov (Sunny)
On Mon, 2005-09-12 at 09:44 -0500, Sunny wrote:
On 9/12/05, Tim Hanson <tjhanson98@comcast.net> wrote:
I have a large jazz CD collection, a lot of which may not be available forever. I'm concerned with things I've read that CDs and DVDs may be subject to deterioration. I also know that CDs can also be damaged by scratches, etc.
I'm familiar with and have successfully used the CD cloning utility of k3b to create a playable (with a standard CD player) duplicate CD, but I want to copy the entire image to my hard drive, so I can keep it there in case the original becomes unplayable later. I have no interest in creating a bunch of duplicate CDs, most of which will never be used in my lifetime.
When I clone directly to my hard drive, the program created two files: k3b_0.img and k3b_0.img.toc. This is fine, but I can't figure out how to write this image to another CD. I've read the documentation that comes with the program without success.
-- "Just once, I wish we would encounter an alien menace that wasn't immune to bullets" -- The Brigader, "Dr. Who"
-- We cannot put the face of a person on a stamp unless said person is deceased. My suggestion, therefore, is that you drop dead. -- James E. Day, Postmaster General
What I do is to encode my CDs with FLAC. It does not lose any quality, and saves like half of the space. Later you can create a CD from the files.
What about ogg. Can you not reverse the conversion to the cda format music cd's use? -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
On 9/14/05, Carl William Spitzer IV <cwsiv@myrealbox.com> wrote:
What I do is to encode my CDs with FLAC. It does not lose any quality, and saves like half of the space. Later you can create a CD from the files.
What about ogg. Can you not reverse the conversion to the cda format music cd's use?
You can do it with mp3 as well :). But as far as I know (I may be wrong) ogg is better than mp3, but still loses some quality, while FLAC is loseless. -- Svetoslav Milenov (Sunny)
tim, i may be late here since your note is months old, but here's another option: (assuming you are running KDE on SuSE) 1) put the cd in the CD-ROM drive and do one of the following: a) type this: audiocd:/ OR if you have a pretty recent version of KDE/SuSE: b) type this instead: media:/ (then click or double click on the icon that says Audio CD) 2) select one of the formats under that view...and there are reasons for each: a) some players/systems only use MP3 so you may want that b) I personally use OGG, because it sounds pretty good to me even when i burn the tracks to CD later c) true audiophiles like to use FLAC it seems, because it's lossless 3) simply drag and drop the tracks to a file on your hard drive...it's really that easy! TIME SAVER/CAVEAT: something I learned was to always be sure I am connected to the internet too, because KDE will usually be able to figure out the name of the song and artist...you may want to go into the Control Center under Audio filenames...and play with that so that it names them how you want automatically...this saves tons of time having to rename files later. hope this helps, wmeler
The problem is not running k3b on cd. There seems to be a prolem with regard to burning DVD+R on k3b. You can burn DVD-R, DVD+RW (don't know about DVD-rw). It seems that the label information that describe the cotnents is messed up in the inital write. I have found that using Nero Linux, I can burn a DVD+R then grow the DVD with k3b with no problem (I have not tried multiple times). If you burn a DVD+R initially, you will have a brand new coster. wmeler wrote:
tim, i may be late here since your note is months old, but here's another option:
(assuming you are running KDE on SuSE)
1) put the cd in the CD-ROM drive and do one of the following: a) type this: audiocd:/
OR if you have a pretty recent version of KDE/SuSE:
b) type this instead: media:/ (then click or double click on the icon that says Audio CD)
2) select one of the formats under that view...and there are reasons for each: a) some players/systems only use MP3 so you may want that b) I personally use OGG, because it sounds pretty good to me even when i burn the tracks to CD later c) true audiophiles like to use FLAC it seems, because it's lossless
3) simply drag and drop the tracks to a file on your hard drive...it's really that easy!
TIME SAVER/CAVEAT: something I learned was to always be sure I am connected to the internet too, because KDE will usually be able to figure out the name of the song and artist...you may want to go into the Control Center under Audio filenames...and play with that so that it names them how you want automatically...this saves tons of time having to rename files later.
hope this helps, wmeler
-- Joseph Loo jloo@acm.org
On Friday 06 January 2006 8:00 pm, Joseph Loo wrote:
There seems to be a prolem with regard to burning DVD+R on k3b. You can burn DVD-R, DVD+RW (don't know about DVD-rw). It seems that the label information that describe the cotnents is messed up in the inital write.
I think that is odd, since my DVD+R discs play just fine. I just did another one to be certain. ( no coasters.) I didn't see your original post , but are you talking about making one of those weird things that leaves the disc open so you add things to it later?
I have found that using Nero Linux, I can burn a DVD+R then grow the DVD
That open ended disc doesn't work very well in Linux as far as I know. In fact if you choose that option in k3b there used to be a warning to that effect.( i.e. It's not 100% safe to do it. That will indeed make coasters of any DVD, or CD you put in.) K3b ,and I thought XCDRoast also, needs to fixate or whatever you call the need to put some logical ending to the recording so various brands of DVD player can recognize and play your discs. -- j Don't try to change my attitude or rearrange my latitude; Don't tell me what I think, I gotta get me some boat drinks
The system is a tame dfi x86-64, with suse 9.3 and kde 3.5 , installed on a new sata drive about a month ago. Since this was my first sata drive, i did a clean install: sda1 a 1gb swap partition, sda2 a 30gb root partition formatted w. reiser fs (first time i let suse install with all it's defaults) and sda3 a 129gb /home partition, which was eventually populated with my previous /home stuff. No problems with the system other than problems with video plugins for firefox & browsers, a standard headache for an x86-64 system. Even had vmware installed and going very nicely. yesterday i used lxdvdrip to backup a couple of dvd's. after the 2nd dvd i received the message that the /tmp space was running short, so i deleted th previous dvd files from /tmp (in the 30gb partition). The files showed deleted, but df showed hardly any free space. somehow, about 15-20 gb of space had gone missing!!!! tried fsck with a rescue run off the suse 9.3 dvd, it said that using fix-fixables would fix the system errors, alas, no results, if anything, even more free space ends up missing if i "delete" things and run df!!!!! Now I am forced to reinstall, I see no way of recovering my clear space in the sda2 partition. Of course it will *not* be formatted w. reiser. Every time i tried it in the past 4 years, it always resulted in a problem, usually major. so, reiserfs is definitely *not* for me. d.
On Saturday 07 January 2006 07:53, kanenas@hawaii.rr.com wrote:
The files showed deleted, but df showed hardly any free space. somehow, about 15-20 gb of space had gone missing!!!!
I'm not familiar with the details of lxdvdrip, but there is one thing that might have happened that could explain things. A file in linux is defined by its hard links. A hard link, briefly put, is an entry in a directory. A file has at least one, and can have several. When you run "rm" on a "file" what you are really doing is deleting a hardlink pointing to the file. But the file isn't really deleted until the last hardlink pointing to it is gone. So for example touch /tmp/foo ln /tmp/foo /tmp/fubar The file now has two hardlinks pointing to it. rm /tmp/foo will remove one of them, but the actual file (in this case empty, but still) is still there, since /tmp/fubar still points to it If you do ls -l /tmp/foo before you run the rm, you will see something like -rw-r--r-- 2 user group 0 2006-01-07 08:24 /tmp/foo The "2" after the permissions is the count of hardlinks pointing to that file
On Saturday 07 January 2006 08:26, Anders Johansson wrote:
what you are really doing is deleting a hardlink pointing to the file. But the file isn't really deleted until the last hardlink pointing to it is gone.
I forgot to mention that when a program has a file open, it will automatically have a hardlink pointing to that file created in /proc/<pid> which will keep the file existing as long as the program is running. But since you were talking about rescue CDs I assume this isn't what's happening. Might be good to know though
Anders, On Friday 06 January 2006 23:32, Anders Johansson wrote:
On Saturday 07 January 2006 08:26, Anders Johansson wrote:
what you are really doing is deleting a hardlink pointing to the file. But the file isn't really deleted until the last hardlink pointing to it is gone.
I forgot to mention that when a program has a file open, it will automatically have a hardlink pointing to that file created in /proc/<pid> which will keep the file existing as long as the program is running. ...
That's not really correct. The entries in /proc/pid/fd are symbolic links and symlinks cannot prevent their targets from being removed. In fact, it doesn't really make sense to say that, since symlinks don't refer to files (by inode number, as directory entries do) but rather are an indirection by name to another directory entry, which need not exist. Randall Schulz
On Saturday 07 January 2006 16:34, Randall R Schulz wrote:
That's not really correct. The entries in /proc/pid/fd are symbolic links and symlinks cannot prevent their targets from being removed.
That should tell you they're not symlinks then. I know they look like symlinks, but a quick test would have told you they don't behave like them ~> echo foo > test.txt ~> ln -s test.txt test2.txt ~> cat test2.txt foo ~> rm test.txt ~> cat test2.txt cat: test2.txt: No such file or directory ~> echo foo > test.txt ~> less test.txt (in new shell) ~> ls -l /proc/10125/fd total 5 lrwx------ 1 andjoh users 64 2006-01-08 00:07 0 -> /dev/pts/6 lrwx------ 1 andjoh users 64 2006-01-08 00:07 1 -> /dev/pts/6 lrwx------ 1 andjoh users 64 2006-01-08 00:07 2 -> /dev/pts/6 lr-x------ 1 andjoh users 64 2006-01-08 00:07 3 -> /dev/tty lr-x------ 1 andjoh users 64 2006-01-08 00:07 4 -> /home/andjoh/test.txt ~> cat /proc/10125/fd/4 foo ~> rm /home/andjoh/test.txt ~> cat /proc/10125/fd/4 foo Things in /proc can't be taken at face value, they're not what they seem. It looks like a symlink, but it behaves like a hardlink
Anders, On Saturday 07 January 2006 15:10, Anders Johansson wrote:
On Saturday 07 January 2006 16:34, Randall R Schulz wrote:
That's not really correct. The entries in /proc/pid/fd are symbolic links and symlinks cannot prevent their targets from being removed.
That should tell you they're not symlinks then. I know they look like symlinks, but a quick test would have told you they don't behave like them
...
Things in /proc can't be taken at face value, they're not what they seem. It looks like a symlink, but it behaves like a hardlink
Well, it does not behave like a hard link, either. For one thing, hard links (directory entries) are just <name, inode-number> pairs, and the file system in which the inode number is looked up is implicitly that of the directory containing the directory entry from which the inode number was read. Besides, for files (inodes) with no directory entries referring to them, it's the internal reference count on the kernel-resident inode structure that prevents reclamation of the inode and its resources (disk blocks), not a faked up directory entry in the proc pseudo-file system. Randall Schulz
On Sunday 08 January 2006 01:07, Randall R Schulz wrote:
Well, it does not behave like a hard link, either. For one thing, hard links (directory entries) are just <name, inode-number> pairs, and the file system in which the inode number is looked up is implicitly that of the directory containing the directory entry from which the inode number was read.
I said it behaved like one, I didn't say it was one. And it does behave like one
Besides, for files (inodes) with no directory entries referring to them, it's the internal reference count on the kernel-resident inode structure that prevents reclamation of the inode and its resources (disk blocks), not a faked up directory entry in the proc pseudo-file system.
huh? When the "faked up" entry in /proc is created it increments the counter in the inode structure. Where is the contradiction?
Anders, On Saturday 07 January 2006 16:20, Anders Johansson wrote:
On Sunday 08 January 2006 01:07, Randall R Schulz wrote:
Well, it does not behave like a hard link, either. For one thing, hard links (directory entries) are just <name, inode-number> pairs, and the file system in which the inode number is looked up is implicitly that of the directory containing the directory entry from which the inode number was read.
I said it behaved like one, I didn't say it was one. And it does behave like one
I disagree. It doesn't behave like anything at all, since it does not exist at all. Not the way any real file system does, with disk blocks, inodes and a directory tree. The /proc pseudo-file system is just a stylized way of presenting kernel data structures.
Besides, for files (inodes) with no directory entries referring to them, it's the internal reference count on the kernel-resident inode structure that prevents reclamation of the inode and its resources (disk blocks), not a faked up directory entry in the proc pseudo-file system.
huh? When the "faked up" entry in /proc is created it increments the counter in the inode structure. Where is the contradiction?
That pseudo-entry in that pseudo-file system is not the internal inode table and it is the reference count in the inode table reaching zero that initiates reclamation of the file's disk resources. Even if that /proc/pid/fd entries did not exist (and they don't), it is the fact that a process has an open file table entry pointing to the inode table entry that prevents inodes with no referring directory entries from being reclaimed. Again, the entries in /proc are just a way of presenting the information from kernel data structures in a manner easily visible to user-level code. They are not primary entities the way actual directory entries are. Randall Schulz
On Sunday 08 January 2006 03:00, Randall R Schulz wrote:
I said it behaved like one, I didn't say it was one. And it does behave like one
I disagree. It doesn't behave like anything at all, since it does not exist at all. Not the way any real file system does, with disk blocks, inodes and a directory tree. The /proc pseudo-file system is just a stylized way of presenting kernel data structures.
You really have a problem with the whole concept of "behaves like", don't you
That pseudo-entry in that pseudo-file system is not the internal inode table and it is the reference count in the inode table reaching zero that initiates reclamation of the file's disk resources. Even if that /proc/pid/fd entries did not exist (and they don't), it is the fact that a process has an open file table entry pointing to the inode table entry that prevents inodes with no referring directory entries from being reclaimed.
Again, the entries in /proc are just a way of presenting the information from kernel data structures in a manner easily visible to user-level code. They are not primary entities the way actual directory entries are.
You're telling me this as if I didn't know it. It *behaves like* a hardlink, regardless of what it actually is. It's know as an abstraction. By way of a simile, I could point out that nothing in the linux virtual file system requires a file system to have inodes, but it does require it to *behave as if* it does. In any case, it's still not "just a symlink", which was what you originally said
Anders, On Saturday 07 January 2006 18:42, Anders Johansson wrote:
On Sunday 08 January 2006 03:00, Randall R Schulz wrote:
I said it behaved like one, I didn't say it was one. And it does behave like one
I disagree. It doesn't behave like anything at all, since it does not exist at all. Not the way any real file system does, with disk blocks, inodes and a directory tree. The /proc pseudo-file system is just a stylized way of presenting kernel data structures.
You really have a problem with the whole concept of "behaves like", don't you
I don't think I have any problems here at all.
...
In any case, it's still not "just a symlink", which was what you originally said
It's as close to a symlink as it is to a hardlink. RRS
On Saturday 07 January 2006 13:10, Anders Johansson wrote:
On Saturday 07 January 2006 16:34, Randall R Schulz wrote:
That's not really correct. The entries in /proc/pid/fd are symbolic links and symlinks cannot prevent their targets from being removed.
That should tell you they're not symlinks then. I know they look like symlinks, but a quick test would have told you they don't behave like them
~> echo foo > test.txt ~> ln -s test.txt test2.txt ~> cat test2.txt foo ~> rm test.txt ~> cat test2.txt cat: test2.txt: No such file or directory
~> echo foo > test.txt ~> less test.txt (in new shell) ~> ls -l /proc/10125/fd total 5 lrwx------ 1 andjoh users 64 2006-01-08 00:07 0 -> /dev/pts/6 lrwx------ 1 andjoh users 64 2006-01-08 00:07 1 -> /dev/pts/6 lrwx------ 1 andjoh users 64 2006-01-08 00:07 2 -> /dev/pts/6 lr-x------ 1 andjoh users 64 2006-01-08 00:07 3 -> /dev/tty lr-x------ 1 andjoh users 64 2006-01-08 00:07 4 -> /home/andjoh/test.txt ~> cat /proc/10125/fd/4 foo ~> rm /home/andjoh/test.txt ~> cat /proc/10125/fd/4 foo
Things in /proc can't be taken at face value, they're not what they seem. It looks like a symlink, but it behaves like a hardlink
Well, i made a bit of a backup, put in the suse 10.0 dvd, in 10 minutes it was purring like it's supposed to do. Now, after about 90% of the apps re-installed, sda2 shows 26+gb free. formatted in ext3 of course. Now i'm off to remove my temp backup files and try to remember what i forgot to install...
Here's a stupid question: have you rebooted the system? mark -- Keep pushing the pebbles. If enough of us keep pushing the pebbles, eventually...the avalanche comes down. - whitroth, 2003
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-01-07 at 10:38 -0500, mark wrote:
Here's a stupid question: have you rebooted the system?
As he said he said he "tried fsck with a rescue run off the suse 9.3 dvd", the answer must be yes. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDwQU0tTMYHG2NR9URAg5DAJ9drEqILdcNy1rTWASbsw6MEGbyBACfdZ6s Y9OuVFukvowoIk7syMG7iYs= =+3ny -----END PGP SIGNATURE-----
On Friday 06 January 2006 21:26, Anders Johansson wrote:
On Saturday 07 January 2006 07:53, kanenas@hawaii.rr.com wrote:
The files showed deleted, but df showed hardly any free space. somehow, about 15-20 gb of space had gone missing!!!!
I'm not familiar with the details of lxdvdrip, but there is one thing that might have happened that could explain things. A file in linux is defined by its hard links. A hard link, briefly put, is an entry in a directory. A file has at least one, and can have several. When you run "rm" on a "file" what you are really doing is deleting a hardlink pointing to the file. But the file isn't really deleted until the last hardlink pointing to it is gone.
So for example
touch /tmp/foo ln /tmp/foo /tmp/fubar
The file now has two hardlinks pointing to it.
rm /tmp/foo
will remove one of them, but the actual file (in this case empty, but still) is still there, since /tmp/fubar still points to it
If you do
ls -l /tmp/foo
before you run the rm, you will see something like
-rw-r--r-- 2 user group 0 2006-01-07 08:24 /tmp/foo
The "2" after the permissions is the count of hardlinks pointing to that file Thanks for the comment Anders. Fyi, while booted on the rescue cd I switched to /tmp in sda2 and ran <rm -r *> . Shouldn't that have cleared everything? Also, is there anything else I can try before reformatting?
On Saturday 07 January 2006 08:38, kanenas@hawaii.rr.com wrote:
Thanks for the comment Anders. Fyi, while booted on the rescue cd I switched to /tmp in sda2 and ran <rm -r *> . Shouldn't that have cleared everything?
Not by default. You would still have all files starting with . To get those, do shopt -s dotglob before running the rm
Also, is there anything else I can try before reformatting?
Well, what is the output you get from df? And what does du -s /tmp say?
On Friday 06 January 2006 21:42, Anders Johansson wrote:
On Saturday 07 January 2006 08:38, kanenas@hawaii.rr.com wrote:
Thanks for the comment Anders. Fyi, while booted on the rescue cd I switched to /tmp in sda2 and ran <rm -r *> . Shouldn't that have cleared everything?
Not by default. You would still have all files starting with . did not see any . files lxdvdrip created the video and audio files for the dvd, and none of them starts with a dot. the directory used by the script was populated with very large video files, each easily over 3 gb.
To get those, do
shopt -s dotglob
before running the rm
Also, is there anything else I can try before reformatting?
Well, what is the output you get from df? And what does
df shows 45 megs ourt of 31 bg free!!!!!. my typical suse installation uses about 4-5 gb of space in all the directories except /home.
du -s /tmp
say?
it saiz: 32 /tmp also, a brief check in /proc did not reveal any phantom pid's with shtuff in them, but i will double check.
kanenas@hawaii.rr.com wrote:
On Friday 06 January 2006 21:42, Anders Johansson wrote:
du -s /tmp
say?
it saiz: 32 /tmp
This seems to indicate that /tmp is nearly empty. On my system I get "7742 /tmp". -- SUSE LINUX 10.0 (i586) -- 2.6.13-15.7-default -- Sat 01/07/06 9:25am up 14 days 16:38, 3 users, load average: 0.00, 0.02, 0.04
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-01-06 at 21:38 -1000, kanenas@hawaii.rr.com wrote:
Also, is there anything else I can try before reformatting?
Try: du -shx --exclude=/proc /* to find out where that missing space is. Or use "mc" for the same thing, then navigate directories to find out the culprit file. For your info, I had once a lot of missing from an ext2 partition: I deleted a large file, but it was several minutes till the space appeared. On the other hand, I have also had several issues with reiserfs partitions. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDwQh9tTMYHG2NR9URAv/FAJ9iE8Of0yMWLTSsPqHxTlN/0KCR/ACfUYmi E5d88uwmtgCrUWTNHF7GeaY= =ggfO -----END PGP SIGNATURE-----
Well, i guess the missing space space problem in the previous thread was not caused by reiserfs!!! After I formatted my root partition to ext3 and install 10.0, I tried my experiment with lxdvdrip, just to be sure: first i configured lxdvdrip to automatically remove the tmp files it creates, then I left the files on disk and used konqueror as an su to delete them. lxdvdrip removed the files properly. Konqueror removed the listing but it *not* free the diskspace!!!! fsck of the xt3 partition shows clean, just has about 4.4 gb less free space! so, i guess i must retract my statement abour reiserfs losing track of free disk space, but i have no idea what's going on and what to do about it!!!! When the problem occurred in 9.3 kde 3.5 was running, 10.0 still has the stock 3.4.2-6 version. I tried to find all large files modified in the last couple of days thru Konqueror, used 1mb first, then 100mb, found a bunch of files but nothing related to the lost space of 4+gb. The missing space is the sum of two files, video.ts and audio.ts plus the space of the directory that had them. video.ts is usually about 4gb, audio.ts about 300mb. Is this a kde problem? does it have a solution?
K, On Sunday 08 January 2006 08:31, kanenas@hawaii.rr.com wrote:
Well, i guess the missing space space problem in the previous thread was not caused by reiserfs!!! After I formatted my root partition to ext3 and install 10.0, I tried my experiment with lxdvdrip, just to be sure: first i configured lxdvdrip to automatically remove the tmp files it creates, then I left the files on disk and used konqueror as an su to delete them. lxdvdrip removed the files properly. Konqueror removed the listing but it *not* free the diskspace!!!! ...
Are you sure you deleted the file, or did you just move it to the trash? If you just, e.g., press the Delete key, you're only moving the file to the trash. SHIFT-Delete will actually remove the file immediately. Furthermore, if you use SHIFT-Delete, you'll be asked a confirming question, since this is not undoable, while putting a file in the trash can be reversed (which is why the file's space is not reclaimed when you issue that command). Randall Schulz
On Sunday 08 January 2006 07:25, Randall R Schulz wrote:
K,
On Sunday 08 January 2006 08:31, kanenas@hawaii.rr.com wrote:
Well, i guess the missing space space problem in the previous thread was not caused by reiserfs!!! After I formatted my root partition to ext3 and install 10.0, I tried my experiment with lxdvdrip, just to be sure: first i configured lxdvdrip to automatically remove the tmp files it creates, then I left the files on disk and used konqueror as an su to delete them. lxdvdrip removed the files properly. Konqueror removed the listing but it *not* free the diskspace!!!! ...
Are you sure you deleted the file, or did you just move it to the trash? If you just, e.g., press the Delete key, you're only moving the file to the trash. SHIFT-Delete will actually remove the file immediately. Furthermore, if you use SHIFT-Delete, you'll be asked a confirming question, since this is not undoable, while putting a file in the trash can be reversed (which is why the file's space is not reclaimed when you issue that command).
Randall Schulz
I just found out that Konqueror "deleted" the files by placing them in /root/.local/share/Trash/files!!! This was done using Carlos's suggestion to run du. I was able to delete the files using <rm>, Konqueror as a superuser could show the listing but it could not delete them. soo, why does kde put these files in an obscure root directory instead of deleting them? That's kde 3.4 and 3.5 btw.
On Sunday 08 January 2006 18:39, kanenas@hawaii.rr.com wrote:
soo, why does kde put these files in an obscure root directory instead of deleting them? That's kde 3.4 and 3.5 btw.
It puts it under root because you were root when you ran it (bad idea, don't log in as root). You have a trashcan icon on your desktop, right click on it and select "empty trash" to really delete Or, as Randall said, use shift-delete to really delete immediately without stopping by the trashcan
On Sunday 08 January 2006 18:39, kanenas@hawaii.rr.com wrote:
soo, why does kde put these files in an obscure root directory instead of deleting them? That's kde 3.4 and 3.5 btw.
It puts it under root because you were root when you ran it (bad idea, don't log in as root). I do *not* run as root. but the file was in /tmp, so i used Konqueror as su. and that led to the problem...
You have a trashcan icon on your desktop, right click on it and select "empty trash" to really delete Yup. do it all the time. but it is useless if one deletes as an su, correct?
Or, as Randall said, use shift-delete to really delete immediately without stopping by the trashcan This might be better, 'cause it avoids the false sense of "security" that emptying the trash gives: I now see that, since the files were deleted as su,
On Sunday 08 January 2006 07:46, Anders Johansson wrote: the trash bin also needed clearing as an su, and kde does not provide an easy way of doing that when logged in as a user!! ah, new things to learn every day...
On Sunday 08 January 2006 19:26, kanenas@hawaii.rr.com wrote:
I now see that, since the files were deleted as su, the trash bin also needed clearing as an su, and kde does not provide an easy way of doing that when logged in as a user!!
In your "konqueror as root" window you can select Go->Trash, then right click in the file view and you should get an option to Empty Trash, and it should clear out root's trash
On Sunday 08 January 2006 11:46, Anders Johansson wrote:
You have a trashcan icon on your desktop, right click on it and select "empty trash" to really delete
Or, as Randall said, use shift-delete to really delete immediately without stopping by the trashcan
Settings / Configure Konqueror... Click "Behavior", then "Show 'Delete' context menu entries which bypass the trashcan" if you don't like this. You can still configure confirmation messages for each independently. -- ====================================================== Glenn Holmer (Linux registered user #16682) ====================================================== "Greater coherence cannot be achieved. Not even the Netherlanders have managed this." -Anton Webern ======================================================
On Sunday 08 January 2006 02:41, Carlos E. R. wrote:
The Friday 2006-01-06 at 21:38 -1000, kanenas@hawaii.rr.com wrote:
Also, is there anything else I can try before reformatting?
Try:
du -shx --exclude=/proc /*
to find out where that missing space is. Or use "mc" for the same thing, then navigate directories to find out the culprit file.
For your info, I had once a lot of missing from an ext2 partition: I deleted a large file, but it was several minutes till the space appeared. On the other hand, I have also had several issues with reiserfs partitions.
-- Cheers, Carlos Robinson Carlos, I saw this post after i started a new thread to remove the reiserfs accusation. I was able to recreate the problem in ext3, in suse 10.0. It should be a kde problem. Using your suggestion (thank you very much:)), du showed a suspicious 4.2g in /root. looking at the sub-directories I found the "deleted" files in:
/root/.local/share/Trash/files I was able to delete them with rm. Konqueror as su could not remove the files. so this problem is *not* a reiserfs problem. but it sure looks like a kde issue!
On Sunday 08 January 2006 18:32, kanenas@hawaii.rr.com wrote:
but it sure looks like a kde issue!
Not at all, it works as designed. See the post from Randall I will not try to start another philosophical discussion on the best way
On Sunday 08 January 2006 07:36, Anders Johansson wrote: things should work, but, if i delete a file, then clear out the trash bin, I would expect said file to be gone. Having to play detective to find what occasionally really happens to a simple delete is not an indicator of a proper design, instead it points to a major KISS violation. d.
On Sunday 08 January 2006 19:13, kanenas@hawaii.rr.com wrote:
I will not try to start another philosophical discussion on the best way things should work, but, if i delete a file, then clear out the trash bin, I would expect said file to be gone.
Am I right in guessing you are logged in as yourself but ran konqueror as root, then tried to clear the trashcan from your own desktop? If you run konqueror as root it will put it in root's trashcan. I hope you don't mean all users should work with one global trashcan
Having to play detective to find what occasionally really happens to a simple delete is not an indicator of a proper design, instead it points to a major KISS violation.
As far as I know, it's the way all major desktops work
On Sunday 08 January 2006 19:13, kanenas@hawaii.rr.com wrote:
I will not try to start another philosophical discussion on the best way things should work, but, if i delete a file, then clear out the trash bin, I would expect said file to be gone.
Am I right in guessing you are logged in as yourself but ran konqueror as root, then tried to clear the trashcan from your own desktop?
If you run konqueror as root it will put it in root's trashcan. I hope you don't mean all users should work with one global trashcan
Having to play detective to find what occasionally really happens to a simple delete is not an indicator of a proper design, instead it points to a major KISS violation.
As far as I know, it's the way all major desktops work The proper design of the trashcan should allow a particular user to remove *all* the deleted files during his/her session. It might be as simple as
On Sunday 08 January 2006 08:25, Anders Johansson wrote: putting all the deleted files -even the ones deleted as an su- into the local trash bin! This could be an enhancement for the future. Until then i will be using the shift-del combo religiously:)
* kanenas@hawaii.rr.com <kanenas@hawaii.rr.com> [01-08-06 13:51]:
The proper design of the trashcan should allow a particular user to remove *all* the deleted files during his/her session. It might be as simple as putting all the deleted files -even the ones deleted as an su- into the local trash bin! This could be an enhancement for the future. Until then i will be using the shift-del combo religiously:)
You may utilize your home machine as you wish, but you are only seeing part of the picture. Linux is a "multi" user system and as such YOU should not as {user} have the ability to delete another users files or empty his trashcan. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
* kanenas@hawaii.rr.com <kanenas@hawaii.rr.com> [01-08-06 13:51]:
The proper design of the trashcan should allow a particular user to remove *all* the deleted files during his/her session. It might be as simple as putting all the deleted files -even the ones deleted as an su- into the local trash bin! This could be an enhancement for the future. Until then i will be using the shift-del combo religiously:)
You may utilize your home machine as you wish, but you are only seeing part of the picture. Linux is a "multi" user system and as such YOU should not as {user} have the ability to delete another users files or empty his trashcan. If I am logged in as user x, in session y, I only want control of the files
On Sunday 08 January 2006 09:04, Patrick Shanahan wrote: that are deleted in session y. Currently, if i switch to su in session y, the deleted files go to root. I only want final delete control of these files, not anyone else's. The simplest way to do that is to put *all* files deleted during my session y in *one* trash bin, controlled by...user x in session y:). It should be simple enough to see that no control over others is sought, Lord knows our government is trying enough of that stupidity...
-- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
* kanenas@hawaii.rr.com <kanenas@hawaii.rr.com> [01-08-06 15:04]:
If I am logged in as user x, in session y, I only want control of the files that are deleted in session y. Currently, if i switch to su in session y, the deleted files go to root.
NO, if you su, you are in a shell and if you rm files, they 'do not' go into a 'trash bucket'. They are removed from existance. There is no worry about them not being GONE.
I only want final delete control of these files, not anyone else's. The simplest way to do that is to put *all* files deleted during my session y in *one* trash bin, controlled by...user x in session y:). It should be simple enough to see that no control over others is sought, Lord knows our government is trying enough of that stupidity...
This has nothing to do with politics. You should join another news group or mailing list if you wish to discuss politics or bash politicians and/or governments. when you 'sh' to root, you are in another session. You are no longer {user}, you are root. that's how *nix was designed. It is not windoz. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-08 at 10:02 -1000, kanenas@hawaii.rr.com wrote:
If I am logged in as user x, in session y, I only want control of the files that are deleted in session y. Currently, if i switch to su in session y, the deleted files go to root. I only want final delete control of these files, not anyone else's. The simplest way to do that is to put *all* files deleted during my session y in *one* trash bin, controlled by...user x in session y:).
Wrong. They are not yours: the moment you "su", you are not longer you. Those files were not deleted in your session, nor by you, but in somebody else's session, by that somebody else (which happens to be root, but might not be). A "su"ed konkeror can not put those files in your home trash, because: a) it doesn't know you want them there b) it does not have permissions to write there c) if you "su"ed to root, you are abusing your position if you write in some body else's trash folder d) it could open security holes. - -- Cheers, Carlos Robinson PS: By the way, when you answer, please delete the signature of the person you are answering to. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDwYe1tTMYHG2NR9URAkJyAKCYOn+d0ZsaMFvig1dyQ+6sEkCLCgCeJYTB bVg43qoGuHHU2AyvwQKYN+0= =lKRb -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-08 at 08:49 -1000, kanenas@hawaii.rr.com wrote: (by the was, if your "from" were of the type «"name" <address>», then your address would not show in our quotations, which is good for spammers and bad for you)
If you run konqueror as root it will put it in root's trashcan. I hope you don't mean all users should work with one global trashcan
Having to play detective to find what occasionally really happens to a simple delete is not an indicator of a proper design, instead it points to a major KISS violation.
As far as I know, it's the way all major desktops work The proper design of the trashcan should allow a particular user to remove *all* the deleted files during his/her session. It might be as simple as putting all the deleted files -even the ones deleted as an su- into the local trash bin!
Certainly not! You have some miss-conceptions that are not correct in a true multiuser system as Linux is. When you do "su", you effectively become another user for (almost) all intents and purposes. You did "su" to root to run konkeror, so konkeror _HAD_ to use the root settings, not yours, and thus, deleted files had to go to the root user trash folder, not yours, because the deleted file was not yours. Konkeror did exactly as it should. However, if konkeror used a system configured trash directory, with one subdirectory there for each user (kind of /Trash/user/*), then those space eaters would be easier to locate. I never use konkeror as root, I use mc - text mode, very powerful, and fast. It has a feature to see directory sizes, for example. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDwXV5tTMYHG2NR9URAjWGAJ0a5U2pxM2uuGvl0lwuj7hroIGYpwCfSMcS tT16LbY+KvYWUG8LKTal9vY= =7kgZ -----END PGP SIGNATURE-----
At 08:49 AM 1/8/2006 -1000, kanenas@hawaii.rr.com wrote: /snip/
The proper design of the trashcan should allow a particular user to remove *all* the deleted files during his/her session. It might be as simple as putting all the deleted files -even the ones deleted as an su- into the local trash bin! This could be an enhancement for the future. Until then i will be using the shift-del combo religiously:)
I don't know if you're suggesting that any user could delete all files in the trash, but that would be a _very_ bad idea. Suppose the other user wants the file back? If you use SHIFT-DELETE, I can guarantee that you'll be sorry within a month or two. Nobody's perfet. --dm -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.1.371 / Virus Database: 267.14.15/223 - Release Date: 1/6/2006
K, On Sunday 08 January 2006 09:32, kanenas@hawaii.rr.com wrote:
... I found the "deleted" files in:
/root/.local/share/Trash/files
I was able to delete them with rm. Konqueror as su could not remove the files.
so this problem is *not* a reiserfs problem.
PEBCAK (<http://www.instantweb.com/foldoc/foldoc.cgi?action3=Home&query=PEBCAK>)
but it sure looks like a kde issue!
Not. RRS
On Sat, 7 Jan 2006 08:26:00 +0100 Anders Johansson <andjoh@rydsbo.net> wrote:
On Saturday 07 January 2006 07:53, kanenas@hawaii.rr.com wrote:
The files showed deleted, but df showed hardly any free space. somehow, about 15-20 gb of space had gone missing!!!!
I'm not familiar with the details of lxdvdrip, but there is one thing that might have happened that could explain things. A file in linux is defined by its hard links. A hard link, briefly put, is an entry in a directory. A file has at least one, and can have several. When you run "rm" on a "file" what you are really doing is deleting a hardlink pointing to the file. But the file isn't really deleted until the last hardlink pointing to it is gone. Very good explanation Anders. Just one additional issue that people don't think of, A file can also have no hard links. This can happen when a file is open, but someone removed the hard link with the rm command. The file is not deleted until the using program closes the file. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Friday 06 January 2006 10:53 pm, kanenas@hawaii.rr.com wrote:
The system is a tame dfi x86-64, with suse 9.3 and kde 3.5 , <snip>
I have heard over and over of peeps having issues with Reiser on the 9.3 systems. In fact, I put 9.3 on my new laptop in July. From then until November (when 10 came out) , I had to run fsck --fix-the-whole-fscking-thing several times. I was really beginning to wonder if my hard drive was bad. However, I have seen so many other peeps having the same issues with Reiser on 9.3 that I firmly believe there is a major problem with it on that release. In fact, since I reformatted and put 10.0 on my laptop in November, I've had zero issues with Reiser. In additon to my laptop, my desktop was upgraded from 9.2 to 10 and has no issues. I've been using Reiser on that system since 9.1 came out. In short, I'd suggest either getting off Reiser on your 9.3 system and moving to something else, or simply upgrading to 10, which seems to come with a better version or implementation of Reiser. -- kai www.perfectreign.com linux - genuine windows replacement part
participants (18)
-
Anders Johansson -
Carl William Spitzer IV -
Carlos E. R. -
Doug McGarrett -
Glenn Holmer -
James Knott -
Jerry Feldman -
jfweber＠bellsouth.net -
Joseph Loo -
Kai Ponte -
kanenas＠hawaii.rr.com -
mark -
Patrick Shanahan -
Randall R Schulz -
Sunny -
Terry Eck -
Tim Hanson -
wmeler