Re: [gentoo-user] Extended file attributes: ext4
On 8 April 2012, at 19:21, Canek Peláez Valdés wrote: … And (optionally) convert all the files and directories to use extends: find directory -xdev -type f -print0 | xargs -0 chattr +e find directory -xdev -type d -print0 | xargs -0 chattr +e Ok, so I was just casually reading the chattr manpage, following this post… The letters `acdeijstuADST' select the new attributes for the files: append only (a), compressed (c), … A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk. COMPRESSED?!?! You mean, all I need to do is `touch new.dd.img chattr +c new.dd.img dd if=/dev/sdX of=new.dd.img` and I never again need to worry about piping dd through bzip and bunzip? If I have a massive great big uncompressed dd image, I can compress it as simply as touching a new file, changing this attribute on the new file and copying it over? Is there a reason I've been unaware of this? Why isn't this hugely popular? Stroller.
Re: [gentoo-user] Extended file attributes: ext4
On Mon, Apr 9, 2012 at 5:06 AM, Stroller strol...@stellar.eclipse.co.uk wrote: On 8 April 2012, at 19:21, Canek Peláez Valdés wrote: … And (optionally) convert all the files and directories to use extends: find directory -xdev -type f -print0 | xargs -0 chattr +e find directory -xdev -type d -print0 | xargs -0 chattr +e Ok, so I was just casually reading the chattr manpage, following this post… The letters `acdeijstuADST' select the new attributes for the files: append only (a), compressed (c), … A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk. COMPRESSED?!?! You mean, all I need to do is `touch new.dd.img chattr +c new.dd.img dd if=/dev/sdX of=new.dd.img` and I never again need to worry about piping dd through bzip and bunzip? If I have a massive great big uncompressed dd image, I can compress it as simply as touching a new file, changing this attribute on the new file and copying it over? Is there a reason I've been unaware of this? Why isn't this hugely popular? From the same man page: BUGS AND LIMITATIONS The `c', 's', and `u' attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels. These attributes may be implemented in future versions of the ext2 and ext3 filesystems. This means ext4 mandatory if you want to use it, and this (usually) means GRUB2, which is still considered beta. Also, I don't see anywhere any mention on the compress algorithm used, which will probably mean bzip or gzip; I really don't think they use something like xz, for example, although maybe it's possible. Even more, it has to have some performance hit, specially on large files; and lastly, with the current harddrive size/price ratio, the option of automatically compress/decompress files is not really that necessary (remember DoubleSpace, from DOS days?). Oh, and I'm not sure about the following, but a *lot* of Unix programs use the same trick to write atomically files: They write the new version to a new file, and if that is successful, it moves the new file over the old one. In this case, I don't know how the new file can be created with the 'c' attribute (unless you set all the files to use it, and then for sure the performance hit will cost you). Anyhow, it's an incredible cool feature; I just don't know how useful it is with the size of modern disks. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Extended file attributes: ext4
On 9 April 2012, at 11:23, Canek Peláez Valdés wrote: … The `c', 's', and `u' attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels. … This means ext4 mandatory if you want to use it, and this (usually) means GRUB2, which is still considered beta. # eix -Ic grub [I] sys-boot/grub (0.97-r10@03/07/12): GNU GRUB boot loader # df -Th Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs228G 5.8G 211G 3% / /dev/root ext4 228G 5.8G 211G 3% / devtmpfs devtmpfs 875M 212K 875M 1% /dev rc-svcdir tmpfs 1.0M 60K 964K 6% /lib64/rc/init.d cgroup_roottmpfs 10M 0 10M 0% /sys/fs/cgroup shmtmpfs 876M 0 876M 0% /dev/shm # Also, I don't see anywhere any mention on the compress algorithm used, which will probably mean bzip or gzip; I really don't think they use something like xz, for example, although maybe it's possible. I was guessing LZMA - I don't believe it's the highest-compression algorithm out there, but it seems to have been around for a while. I'm pretty sure I've seen it in menuconfig's kernel options somewhere. Even more, it has to have some performance hit, specially on large files; Sure, but that applies to all file compression. and lastly, with the current harddrive size/price ratio, the option of automatically compress/decompress files is not really that necessary (remember DoubleSpace, from DOS days?). Yeah, in my case I've got about 1TB consumed by dd disk images which I've had to copy and unpack so I can mount them as loopback. These images are of the installed gentoo, got it booting, zero'd over the free space and factory-installation of Linpus types - i.e 5GB to 20GB when compressed. But the files are so huge because the system has this big empty 250GB or 500GB hard-drive installed from the factory, and I'm just dd'ing the whole thing, because who cares for more elegant methods when you're bzipping them, anyway, and you can just leave the copy running overnight? So this is a present issue for me right now. Oh, and I'm not sure about the following, but a *lot* of Unix programs use the same trick to write atomically files: They write the new version to a new file, and if that is successful, it moves the new file over the old one. In this case, I don't know how the new file can be created with the 'c' attribute (unless you set all the files to use it, and then for sure the performance hit will cost you). Yeah, I got the notion from `man chattr` (with the `c' attribute set … A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk.) that one might be initiate the dd copying process to a new file (which would write uncompressed data) then, in a new terminal, immediately change the compression attribute of the file, and that the *remainder* of the file would be compressed. I was saving this speculation to wait hopefully for a reply from someone who has actually used this feature. Stroller.
Re: [gentoo-user] Extended file attributes: ext4
On Mon, 9 Apr 2012 12:35:44 +0100, Stroller wrote: Yeah, I got the notion from `man chattr` (with the `c' attribute set … A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk.) that one might be initiate the dd copying process to a new file (which would write uncompressed data) then, in a new terminal, immediately change the compression attribute of the file, and that the *remainder* of the file would be compressed. It appears that you can set this attribute on a directory then all files created in that directory will inherit it. -- Neil Bothwick Don't be humble, you're not that great. signature.asc Description: PGP signature
Re: [gentoo-user] Extended file attributes: ext4
On Mon, Apr 9, 2012 at 6:35 AM, Stroller strol...@stellar.eclipse.co.uk wrote: On 9 April 2012, at 11:23, Canek Peláez Valdés wrote: … The `c', 's', and `u' attributes are not honored by the ext2 and ext3 filesystems as implemented in the current mainline Linux kernels. … This means ext4 mandatory if you want to use it, and this (usually) means GRUB2, which is still considered beta. # eix -Ic grub [I] sys-boot/grub (0.97-r10@03/07/12): GNU GRUB boot loader # df -Th Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 228G 5.8G 211G 3% / /dev/root ext4 228G 5.8G 211G 3% / devtmpfs devtmpfs 875M 212K 875M 1% /dev rc-svcdir tmpfs 1.0M 60K 964K 6% /lib64/rc/init.d cgroup_root tmpfs 10M 0 10M 0% /sys/fs/cgroup shm tmpfs 876M 0 876M 0% /dev/shm # Interesting. Do you have extents enabled in the filesystem? Mine does: # tune2fs -l /dev/sda4 | grep features Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file uninit_bg I was under the impression that GRUB legacy could not read ext4 filesystems with extents enabled; that was the primary reason I migrated to GRUB2. I believe there is a patch for GRUB legacy which adds ext4+extents support, but I don't think Gentoo applies it. If GRUB legacy supports ext4 from upstream, then it's a new feature (or certainly, I hadn't heard about it until now). Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Extended file attributes: ext4
On Mon, Apr 9, 2012 at 6:06 AM, Stroller strol...@stellar.eclipse.co.uk wrote: On 8 April 2012, at 19:21, Canek Peláez Valdés wrote: … And (optionally) convert all the files and directories to use extends: find directory -xdev -type f -print0 | xargs -0 chattr +e find directory -xdev -type d -print0 | xargs -0 chattr +e Ok, so I was just casually reading the chattr manpage, following this post… The letters `acdeijstuADST' select the new attributes for the files: append only (a), compressed (c), … A file with the `c' attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk. COMPRESSED?!?! You mean, all I need to do is `touch new.dd.img chattr +c new.dd.img dd if=/dev/sdX of=new.dd.img` and I never again need to worry about piping dd through bzip and bunzip? If I have a massive great big uncompressed dd image, I can compress it as simply as touching a new file, changing this attribute on the new file and copying it over? Is there a reason I've been unaware of this? Why isn't this hugely popular? Stroller. From the kernel sources, Documentation/filesystems/ext2.txt: Specification = ext2 shares many properties with traditional Unix filesystems. It has the concepts of blocks, inodes and directories. It has space in the specification for Access Control Lists (ACLs), fragments, undeletion and compression though these are not yet implemented (some are available as separate patches). There is also a versioning mechanism to allow new features (such as journalling) to be added in a maximally compatible manner. So, ext2's extended attribute set listed support for compression (among other things), but it wasn't implemented. None of the other ext*.txt files reference compression. Digging into the kenrel source for ext4 in linux-3.2.1.-gentoo-r2, there are symbols defined for managing compression, but they're not used. In short, compression support is specced, but not implemented. -- :wq
[gentoo-user] Sony AVCHD
Hello, In a previous thread (3apr2012 - MTS player) I delineated some problems with the copy of files from a new HD sony camcorder to my gentoo system. This explains the nature of the problem: snip Files with CPI file extension are stored on the hard disk or memory card of AVHCD camcorders. File contains information (metadata) about captured video such as aspect ratio, frame rate and other information. CPI files are usually found in the AVCHD/BDMV/CLIPINF directory of the HD digital video recording media. The AVCHD is a brand new high definition (HD) digital video camera recorder format recording 1080i and 720p signals onto certain media by using highly efficient codec technologies. The AVCHD is jointly established by Panasonic Corporation and Sony Corporation. end/snip Here are some things I have learned along the way that other might find useful: 1. Reverse Engineering the Microsoft exFAT File System is an excellent expose on learning about exFAT, which my new sony HDR-PJ760V camcorder uses. Facinating read for those interested in SD (SDHC and SDXC). 2. The trouble I was having, appeared to occur periodically, so initially I thought it was due to some protection scheme encoded by sony into their newer camcorders. What I found by trial and error is that auto-usb-mount (I just clicked on the Dolphin file manager each time the usb cable was inserted and click the usb-connect icon on the camcorder) is very sensitive and drops easily. Sure you can sometime just reinitialize the connection form the gentoo-kde tools, or sometime you need to reinitialize from the camcorder usb-connect gui. Some times you have to power cycle the camcorder and start with a fresh session to continue the copy process. So the usb-connections from my gentoo system to this sony camcorder is FRAGILE, for unknown reasons. 3. So, I removed the extra SD card I had installed and made sure that the auto lens cover was toggled to close and I was able to copy the files over with plain old cp across the auto-usb-mount provided via dolphin. The auto link then was stable enough to use this command: cp 0007[0-9].MTS /usr/local/TR/ To copy the files over. Use of a wildcard to copy files with one command, failed regardless of what I did. So, I lost the originating file information, not thinking about date/time stamps: (sony camcorder internal flash) -rw-r--r-- 1 james james 122M Mar 31 15:25 00053.MTS -rw-r--r-- 1 james james 173M Mar 31 15:27 00054.MTS -rw-r--r-- 1 james james 68M Mar 31 15:28 00055.MTS -rw-r--r-- 1 james james 22M Mar 31 15:29 00056.MTS cp yeilded this: (gentoo drive) -rw--- 1 root root 122M Apr 9 10:20 00053.MTS -rw--- 1 root root 173M Apr 9 10:32 00054.MTS -rw--- 1 root root 68M Apr 9 10:33 00055.MTS -rw--- 1 root root 22M Apr 9 10:34 00056.MTS So, not being the swiftest tack in the box on the use of rsync, could somebody suggest some detailed rsync syntax to correct the date/time stamp on the file in the gentoo host dir without other harm. Note the cp proceedure is very slow, suggesting that using rate limiting on the file transfer is probably a good idea? cp does not have a rate limited option, so should I try scp or rsync (syntax examples are most appreciated). I also saw a script that used sleep 10 but that would only work between file names thoughts, comments and suggestions are most welcome. James
[gentoo-user] KDE compose key with Fluxbox
The gruesome details cb found in KDE bug 294949 . I want to be able to enter Greek other special characters in Kwrite/Kate using a compose key, as I can already in Gvim. This doesn't work with Fluxbox, but does work with the KDE desktop. That suggests some daemon or service needs to be running, which is started by 'startkde' but not by Fluxbox, which then recognises the compose key behaves accordingly. Can anyone suggest what the daemon or service mb how to add it to ~/.xinitrc so that it starts with Fluxbox ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] User can mount/umount but not write to top the new drive
Hi, This has long been a sort of hack area of me in terms of sys admin at home - giving a user account access to the top of a new external drive. I'd like to learn to do this right. Maybe someone can set me straight about what root needs to do to make this work. OK, so as root I partition format the USB drive to get it ready, and then I modify fstab with the following addition: c2stable ~ # cat /etc/fstab | grep VideoLib LABEL=VideoLib /mnt/VideoLib ext3 auto,rw,users 0 0 c2stable ~ # Having done that, as well as making the /mnt/VideoLib mount point, my user account can now mount umount the drive: mark@c2stable ~ $ mount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib /dev/sdf1 458G 199M 435G 1% /mnt/VideoLib mark@c2stable ~ $ umount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib mark@c2stable ~ $ The problem is that at this point my user account cannot create a new directory on that drive: mark@c2stable ~ $ mount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib /dev/sdf1 458G 199M 435G 1% /mnt/VideoLib mark@c2stable ~ $ mkdir /mnt/VideoLib/Video mkdir: cannot create directory `/mnt/VideoLib/Video': Permission denied mark@c2stable ~ $ In the past I've gotten around this by having root mount the drive and then change ownership to mark:users once it's mounted. Linux remembers I've done that once and no longer requires me to do anything else as root. Is that truly required or is there a way to give the user access to the top of the new mount point without roots' involvement? Thanks, Mark
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, Apr 9, 2012 at 2:59 PM, Mark Knecht markkne...@gmail.com wrote: Hi, This has long been a sort of hack area of me in terms of sys admin at home - giving a user account access to the top of a new external drive. I'd like to learn to do this right. Maybe someone can set me straight about what root needs to do to make this work. OK, so as root I partition format the USB drive to get it ready, and then I modify fstab with the following addition: c2stable ~ # cat /etc/fstab | grep VideoLib LABEL=VideoLib /mnt/VideoLib ext3 auto,rw,users 0 0 c2stable ~ # Having done that, as well as making the /mnt/VideoLib mount point, my user account can now mount umount the drive: mark@c2stable ~ $ mount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib /dev/sdf1 458G 199M 435G 1% /mnt/VideoLib mark@c2stable ~ $ umount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib mark@c2stable ~ $ The problem is that at this point my user account cannot create a new directory on that drive: mark@c2stable ~ $ mount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib /dev/sdf1 458G 199M 435G 1% /mnt/VideoLib mark@c2stable ~ $ mkdir /mnt/VideoLib/Video mkdir: cannot create directory `/mnt/VideoLib/Video': Permission denied mark@c2stable ~ $ In the past I've gotten around this by having root mount the drive and then change ownership to mark:users once it's mounted. Linux remembers I've done that once and no longer requires me to do anything else as root. Is that truly required or is there a way to give the user access to the top of the new mount point without roots' involvement? Have you tried: # cat /etc/fstab | grep VideoLib LABEL=VideoLib /mnt/VideoLib ext3 auto,rw,users,uid=X,gid=Y 0 0 where X is mark's user id, and Y is users' group id? On the other hand, do you use a desktop environment? Because GNOME does everything you want for you, and I suppose KDE does the same. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, 9 Apr 2012 12:59:31 -0700, Mark Knecht wrote: In the past I've gotten around this by having root mount the drive and then change ownership to mark:users once it's mounted. Linux remembers I've done that once and no longer requires me to do anything else as root. That's right, the root of the filesystem is now owned by mark. Is that truly required or is there a way to give the user access to the top of the new mount point without roots' involvement? Not with a Linux filesystem[1][2], because the filesystem is owned by root, so only root can change that. [1] This isn't strictly true as you can do it with ACLs, but that is far more complex than simply chowning the root of the filesystem if that is all you need. [2] With Windows filesystem, there are mount options to set the default ownership, but that is a workaround for the differences between Linux and Windows metadata. -- Neil Bothwick TROI : What am I sensing?? I'm sensing INCOMPETENCE, you pretentious bald pseudo-French dickweed! signature.asc Description: PGP signature
[gentoo-user] Unable to downgrade media-video/ffmpeg-0.10 using package.mask
Today portage upgraded ffmpeg from 0.7.8 to 0.10. I do not want to the new version (0.10). I attempted to indicate this to portage, using 'man portage' as a guide, by changing package.mask: crs-m6600 ~ # cat /etc/portage/package.mask # Avoid dealing with deprecated functions that break SimLib =media-video/ffmepg-0.10 crs-m6600 ~ # Portage, however, appears unwilling to downgrade me back to 0.7.8: crs-m6600 ~ # emerge -p ffmpeg These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] media-video/ffmpeg-0.10 crs-m6600 ~ # Note: I have tried two additional representations of ffmpeg in /etc/portage/package.mask: media-video/ffmepg-0.7 media-video/ffmepg-0.7.8 but still portage will not downgrade me. Q1: Why did none of my three ffmpeg mask attempts cause portage to downgrade me from media-video/ffmpeg-0.10 to media-video/ffmpeg-0.7.8? Q2: What is the proper way to tell portage to not upgrade me past ffmpeg-0.7.8? Q3: What is the proper way to tell portage to downgrade me from ffmpeg-0.10.0 to ffmpeg-0.7.8? FYI: I am trying to avoid ffmpeg-0.10 as it removes a public function I am using elsewhere. Thank you, Chris
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, Apr 9, 2012 at 1:38 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Apr 9, 2012 at 2:59 PM, Mark Knecht markkne...@gmail.com wrote: Hi, This has long been a sort of hack area of me in terms of sys admin at home - giving a user account access to the top of a new external drive. I'd like to learn to do this right. Maybe someone can set me straight about what root needs to do to make this work. OK, so as root I partition format the USB drive to get it ready, and then I modify fstab with the following addition: c2stable ~ # cat /etc/fstab | grep VideoLib LABEL=VideoLib /mnt/VideoLib ext3 auto,rw,users 0 0 c2stable ~ # Having done that, as well as making the /mnt/VideoLib mount point, my user account can now mount umount the drive: mark@c2stable ~ $ mount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib /dev/sdf1 458G 199M 435G 1% /mnt/VideoLib mark@c2stable ~ $ umount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib mark@c2stable ~ $ The problem is that at this point my user account cannot create a new directory on that drive: mark@c2stable ~ $ mount /mnt/VideoLib/ mark@c2stable ~ $ df -h | grep VideoLib /dev/sdf1 458G 199M 435G 1% /mnt/VideoLib mark@c2stable ~ $ mkdir /mnt/VideoLib/Video mkdir: cannot create directory `/mnt/VideoLib/Video': Permission denied mark@c2stable ~ $ In the past I've gotten around this by having root mount the drive and then change ownership to mark:users once it's mounted. Linux remembers I've done that once and no longer requires me to do anything else as root. Is that truly required or is there a way to give the user access to the top of the new mount point without roots' involvement? Have you tried: # cat /etc/fstab | grep VideoLib LABEL=VideoLib /mnt/VideoLib ext3 auto,rw,users,uid=X,gid=Y 0 0 where X is mark's user id, and Y is users' group id? On the other hand, do you use a desktop environment? Because GNOME does everything you want for you, and I suppose KDE does the same. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I had not tried those but they seem to cause problems so clearly I don't have it right yet: c2stable ~ # cat /etc/fstab | grep VideoLib LABEL=VideoLib /mnt/VideoLib ext3 auto,rw,users,uid=1000,gid=100 0 0 c2stable ~ # mark@c2stable ~ $ mount /mnt/VideoLib/ mount: wrong fs type, bad option, bad superblock on /dev/sdf1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so mark@c2stable ~ $ I tried both uid=X,gid=Y and setuid=X,setgid=Y Same results. The man page sure reads like that should work but it didn't. Thanks, Mark
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, Apr 9, 2012 at 1:48 PM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 9 Apr 2012 12:59:31 -0700, Mark Knecht wrote: In the past I've gotten around this by having root mount the drive and then change ownership to mark:users once it's mounted. Linux remembers I've done that once and no longer requires me to do anything else as root. That's right, the root of the filesystem is now owned by mark. Is that truly required or is there a way to give the user access to the top of the new mount point without roots' involvement? Not with a Linux filesystem[1][2], because the filesystem is owned by root, so only root can change that. [1] This isn't strictly true as you can do it with ACLs, but that is far more complex than simply chowning the root of the filesystem if that is all you need. [2] With Windows filesystem, there are mount options to set the default ownership, but that is a workaround for the differences between Linux and Windows metadata. -- Neil Bothwick TROI : What am I sensing?? I'm sensing INCOMPETENCE, you pretentious bald pseudo-French dickweed! Thanks Neil. I guess that unless we figure out Canek's uid/gid options I'll stick with chown, etc. Cheers, Mark
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, 9 Apr 2012 14:23:13 -0700, Mark Knecht wrote: [2] With Windows filesystem, there are mount options to set the default ownership, but that is a workaround for the differences between Linux and Windows metadata. Thanks Neil. I guess that unless we figure out Canek's uid/gid options I'll stick with chown, etc. The uid and gid options don't apply to ext? filesystems. Have another look at the man page and you'll see they are only listed for some non-Linux filesystems, in order to make them compatible with Linux ownerships and permissions. -- Neil Bothwick God: What one human uses to persecute another. signature.asc Description: PGP signature
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, Apr 9, 2012 at 4:39 PM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 9 Apr 2012 14:23:13 -0700, Mark Knecht wrote: [2] With Windows filesystem, there are mount options to set the default ownership, but that is a workaround for the differences between Linux and Windows metadata. Thanks Neil. I guess that unless we figure out Canek's uid/gid options I'll stick with chown, etc. The uid and gid options don't apply to ext? filesystems. Have another look at the man page and you'll see they are only listed for some non-Linux filesystems, in order to make them compatible with Linux ownerships and permissions. Oh crap, you are totally right. Sorry for the noise. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, Apr 9, 2012 at 2:39 PM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 9 Apr 2012 14:23:13 -0700, Mark Knecht wrote: [2] With Windows filesystem, there are mount options to set the default ownership, but that is a workaround for the differences between Linux and Windows metadata. Thanks Neil. I guess that unless we figure out Canek's uid/gid options I'll stick with chown, etc. The uid and gid options don't apply to ext? filesystems. Have another look at the man page and you'll see they are only listed for some non-Linux filesystems, in order to make them compatible with Linux ownerships and permissions. -- Neil Bothwick God: What one human uses to persecute another. Apparently Canek I do need to read more carefully. I just zoomed in on the gid stuff from searching. I should have read the whole area. Thanks OK, so mounting the drive and chown-ing as root is indeed the right way to go. Thanks, Mark
Re: [gentoo-user] Unable to downgrade media-video/ffmpeg-0.10 using package.mask
On Apr 10, 2012 3:58 AM, Chris Stankevitz chrisstankev...@gmail.com wrote: Today portage upgraded ffmpeg from 0.7.8 to 0.10. I do not want to the new version (0.10). I attempted to indicate this to portage, using 'man portage' as a guide, by changing package.mask: crs-m6600 ~ # cat /etc/portage/package.mask # Avoid dealing with deprecated functions that break SimLib =media-video/ffmepg-0.10 crs-m6600 ~ # If that's your exact console output, no wonder... ffmepg != ffmpeg Rgds,
Re: [gentoo-user] Sony AVCHD
On Monday 09 Apr 2012 16:56:42 James wrote: Hello, In a previous thread (3apr2012 - MTS player) I delineated some problems with the copy of files from a new HD sony camcorder to my gentoo system. This explains the nature of the problem: snip Files with CPI file extension are stored on the hard disk or memory card of AVHCD camcorders. File contains information (metadata) about captured video such as aspect ratio, frame rate and other information. CPI files are usually found in the AVCHD/BDMV/CLIPINF directory of the HD digital video recording media. The AVCHD is a brand new high definition (HD) digital video camera recorder format recording 1080i and 720p signals onto certain media by using highly efficient codec technologies. The AVCHD is jointly established by Panasonic Corporation and Sony Corporation. end/snip Here are some things I have learned along the way that other might find useful: 1. Reverse Engineering the Microsoft exFAT File System is an excellent expose on learning about exFAT, which my new sony HDR-PJ760V camcorder uses. Facinating read for those interested in SD (SDHC and SDXC). 2. The trouble I was having, appeared to occur periodically, so initially I thought it was due to some protection scheme encoded by sony into their newer camcorders. What I found by trial and error is that auto-usb-mount (I just clicked on the Dolphin file manager each time the usb cable was inserted and click the usb-connect icon on the camcorder) is very sensitive and drops easily. Sure you can sometime just reinitialize the connection form the gentoo-kde tools, or sometime you need to reinitialize from the camcorder usb-connect gui. Some times you have to power cycle the camcorder and start with a fresh session to continue the copy process. So the usb-connections from my gentoo system to this sony camcorder is FRAGILE, for unknown reasons. 3. So, I removed the extra SD card I had installed and made sure that the auto lens cover was toggled to close and I was able to copy the files over with plain old cp across the auto-usb-mount provided via dolphin. The auto link then was stable enough to use this command: cp 0007[0-9].MTS /usr/local/TR/ To copy the files over. Use of a wildcard to copy files with one command, failed regardless of what I did. So, I lost the originating file information, not thinking about date/time stamps: (sony camcorder internal flash) -rw-r--r-- 1 james james 122M Mar 31 15:25 00053.MTS -rw-r--r-- 1 james james 173M Mar 31 15:27 00054.MTS -rw-r--r-- 1 james james 68M Mar 31 15:28 00055.MTS -rw-r--r-- 1 james james 22M Mar 31 15:29 00056.MTS cp yeilded this: (gentoo drive) -rw--- 1 root root 122M Apr 9 10:20 00053.MTS -rw--- 1 root root 173M Apr 9 10:32 00054.MTS -rw--- 1 root root 68M Apr 9 10:33 00055.MTS -rw--- 1 root root 22M Apr 9 10:34 00056.MTS So, not being the swiftest tack in the box on the use of rsync, could somebody suggest some detailed rsync syntax to correct the date/time stamp on the file in the gentoo host dir without other harm. Note the cp proceedure is very slow, suggesting that using rate limiting on the file transfer is probably a good idea? cp does not have a rate limited option, so should I try scp or rsync (syntax examples are most appreciated). I also saw a script that used sleep 10 but that would only work between file names thoughts, comments and suggestions are most welcome. Notwithstanding the problems with intermittent connections you're describing, rsync -v -a /source /destination should do what you're after. You may also want to add --stats --progress to see some more info, -R to mirror directory/subdirectory hierarchies and you may also want to add -n for a dry run before you let rip. The manual shows more options, should you need them. HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Unable to downgrade media-video/ffmpeg-0.10 using package.mask
On Mon, Apr 9, 2012 at 3:14 PM, Pandu Poluan pa...@poluan.info wrote: ffmepg != ffmpeg Pandu, I had to reread your email a few times and I finally get it. Thank you, Chris
Re: [gentoo-user] KDE compose key with Fluxbox
On Monday 09 Apr 2012 20:35:33 Philip Webb wrote: The gruesome details cb found in KDE bug 294949 . I want to be able to enter Greek other special characters in Kwrite/Kate using a compose key, as I can already in Gvim. This doesn't work with Fluxbox, but does work with the KDE desktop. That suggests some daemon or service needs to be running, which is started by 'startkde' but not by Fluxbox, which then recognises the compose key behaves accordingly. Can anyone suggest what the daemon or service mb how to add it to ~/.xinitrc so that it starts with Fluxbox ? Old school here, I add the second keyboard as Option XkbLayout in my xorg.conf and Option XkbOptions grp:alt_shift_toggle,grp_led:scroll to be able to use Alt+Shift to activate it. I just thought that I don't know how to make this work on the console without X. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] User can mount/umount but not write to top the new drive
On Mon, Apr 9, 2012 at 5:39 PM, Neil Bothwick n...@digimed.co.uk wrote: On Mon, 9 Apr 2012 14:23:13 -0700, Mark Knecht wrote: [2] With Windows filesystem, there are mount options to set the default ownership, but that is a workaround for the differences between Linux and Windows metadata. Thanks Neil. I guess that unless we figure out Canek's uid/gid options I'll stick with chown, etc. The uid and gid options don't apply to ext? filesystems. Have another look at the man page and you'll see they are only listed for some non-Linux filesystems, in order to make them compatible with Linux ownerships and permissions. Wouldn't it at least apply to the / mount point? (Which is the only one at issue here, anyway...) -- :wq
