On 9/14/05, Carl William Spitzer IV 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)

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

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 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

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

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 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?

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

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...

mark wrote:

Here's a stupid question: have you rebooted the system?

Reboot? Linux???

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 . Shouldn't that have cleared everything? Also, is there anything else I can try before reformatting?

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 . 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.

-----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-----

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 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 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 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 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 [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

-----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-----

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

On Sat, 7 Jan 2006 08:26:00 +0100 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. 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 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