search for: imgfil

...m("sheepfs -n " + sheepfs_dir) 0 >>> vdi_name = "vm1935028.nbregion.ec2.cloudkc.cn" >>> os.system("echo " + vdi_name + ">" + sheepfs_dir + "/vdi/mount") 0 >>> import guestfs >>> g=guestfs.GuestFS() >>> imgfile=sheepfs_dir + "/volume/" + vdi_name >>> g.add_drive_opts(imgfile, format="raw", readonly=0) >>> g.launch() >>> root = g.inspect_os() >>> print root [] >>> g.list_filesystems() [('/dev/vda1', 'ntfs'), ('/dev/vda2...

...4.3.9 that i am thinking for me that version is enough stable the last version doesn't have any more the "Authenticated Users" it is active directory my server setup i am suspicious that is something wrong when i am connecting to a loop device that is made this way dd if=/dev/zero of=imgfile bs=1M count=60 for example then losetup /dev/loop0 imgfile and formating it as ext4 filesystem but only root have there write access am i doing something wrong? this path is connected to a smb.conf with the following way: [test] path = /path (where is mounted the loop device) re...

...eatmap on a square matrix and wouldn't want to reorder the columns and the rows on the heatmap display.    I have used the options Rowv=NULL and Colv=NULL but doesn't seem to work. Following is a snippet of the heatmap function i am using. args <- commandArgs(); inputfile <- args[2] imgfile   <- args[3] bitmap(imgfile, height=15, width=15, res=100, pointsize=9) library(gplots) library(RColorBrewer) data <- read.table(inputfile) matrix <- as.matrix(data) cp <- colorRampPalette(c("red","yellow","darkgreen"),space="Lab", bias=1.5) he...

...d, 106 insertions(+), 3 deletions(-) diff --git a/daemon/xfs.c b/daemon/xfs.c index b331b9b..b32d256 100644 --- a/daemon/xfs.c +++ b/daemon/xfs.c @@ -460,3 +460,81 @@ error: if (out) free (out); return NULL; } + +char * +do_xfs_admin (const char *device, + int extunwritten, int imgfile, int v2log, + int printlabel, int projid32bit, int printuuid, + int lazycounter, const char *label, const char *uuid) +{ + int r; + char *out = NULL, *err = NULL; + const char *argv[MAX_ARGS]; + size_t i = 0; + + ADD_ARG (argv, i, "xfs_admin"); + + /* Opti...

...| 2 +- 5 files changed, 145 insertions(+), 3 deletions(-) diff --git a/daemon/xfs.c b/daemon/xfs.c index 12ed600..8a86f93 100644 --- a/daemon/xfs.c +++ b/daemon/xfs.c @@ -536,3 +536,119 @@ error: free (err); return -1; } + +int +do_xfs_repair (const char *device, + int imgfile, int forcelogzero, int dangerous, + int nomodify, int noprefetch, int forcegeometry, + int64_t maxmem, int64_t ihashsize, + int64_t bhashsize, int64_t agstride, + const char *logdev, const char *rtdev) +{ + int r; + char *err = NULL; + const c...

...ou create new users? Are you using those new users on > the Windows workstation? > > If it is a domain member, how did you join the AD domain? > > i am suspicious that is something >> wrong when i am connecting to a loop device that is made this way dd >> if=/dev/zero of=imgfile bs=1M count=60 for example >> then losetup /dev/loop0 imgfile and formating it as ext4 filesystem >> >> but only root have there write access am i doing something wrong? >> > > No, that's normal. An ext4 filesystem supports permissions, and you must > manually...

...o the domain? How did you create new users? Are you using those new users on the Windows workstation? If it is a domain member, how did you join the AD domain? > i am suspicious that is something > wrong when i am connecting to a loop device that is made this way dd > if=/dev/zero of=imgfile bs=1M count=60 for example > then losetup /dev/loop0 imgfile and formating it as ext4 filesystem > > but only root have there write access am i doing something wrong? No, that's normal. An ext4 filesystem supports permissions, and you must manually set them to allow users to write...

...u using those new users on >> the Windows workstation? >> >> If it is a domain member, how did you join the AD domain? >> >> i am suspicious that is something >>> wrong when i am connecting to a loop device that is made this way dd >>> if=/dev/zero of=imgfile bs=1M count=60 for example >>> then losetup /dev/loop0 imgfile and formating it as ext4 filesystem >>> >>> but only root have there write access am i doing something wrong? >>> >> >> No, that's normal. An ext4 filesystem supports permissions, an...

ok here is my view code: <% for img in ary %> <%= resize_image img.name %> # img.name= /homa/joe/pictureimg.jpg <% end %> here is my resize_image code in application_helper: def resize_image(imgfile) pic = Magick::Image.read(imgfile).first thumb = pic.crop_resized(maxwidth, maxheight, gravity=Magick::CenterGravity) thumb.write(imgfile+''thumb'') end What happens: When "ary" contains 50 images to resize, it goes fast on the first 4 images then the whole t...

..._dir) > 0 > >>> vdi_name = "vm1935028.nbregion.ec2.cloudkc.cn" > >>> os.system("echo " + vdi_name + ">" + sheepfs_dir + "/vdi/mount") > 0 > >>> import guestfs > >>> g=guestfs.GuestFS() > >>> imgfile=sheepfs_dir + "/volume/" + vdi_name > >>> g.add_drive_opts(imgfile, format="raw", readonly=0) > >>> g.launch() > >>> root = g.inspect_os() > >>> print root > [] So libguestfs can't find any guest(s) in the disk image. I s...

..._dir) > 0 > >>> vdi_name = "vm1935028.nbregion.ec2.cloudkc.cn" > >>> os.system("echo " + vdi_name + ">" + sheepfs_dir + "/vdi/mount") > 0 > >>> import guestfs > >>> g=guestfs.GuestFS() > >>> imgfile=sheepfs_dir + "/volume/" + vdi_name > >>> g.add_drive_opts(imgfile, format="raw", readonly=0) > >>> g.launch() > >>> root = g.inspect_os() > >>> print root > [] So libguestfs can't find any guest(s) in the disk image. I s...

i make a image file connected to /dev/loop0 formated as ext4 partition and connect it losetup /dev/loop0 /root/disk.img then make format the loop drive with mkfs.ext4 -o rw,usrquota,grpquota /dev/loop0 /disk connected it to /test the only way to write there other users except root is setting with chmod o+w /test from windows 7 using samba 4 i can write to folder but i cannot set security

...t char *device, const char *uuid) } int +xfs_set_uuid_random (const char *device) +{ + optargs_bitmask = GUESTFS_XFS_ADMIN_UUID_BITMASK; + return do_xfs_admin (device, 0, 0, 0, 0, 0, NULL, "generate"); +} + +int do_xfs_admin (const char *device, int extunwritten, int imgfile, int v2log, int projid32bit, diff --git a/generator/actions.ml b/generator/actions.ml index b1865e0..fb4a174 100644 --- a/generator/actions.ml +++ b/generator/actions.ml @@ -12636,6 +12636,25 @@ removed from the filesystem. The C<targetdev> needs to be same size or larger tha...

...do_xfs_growfs (const char *path, } int +do_xfs_admin_uuid (const char *device, const char *uuid) +{ + optargs_bitmask = GUESTFS_XFS_ADMIN_UUID_BITMASK; + return do_xfs_admin (device, 0, 0, 0, 0, 0, NULL, uuid); +} + +int do_xfs_admin (const char *device, int extunwritten, int imgfile, int v2log, int projid32bit, -- 2.1.0

...13 @@ do_xfs_growfs (const char *path, } int +xfs_set_uuid (const char *device, const char *uuid) +{ + optargs_bitmask = GUESTFS_XFS_ADMIN_UUID_BITMASK; + return do_xfs_admin (device, 0, 0, 0, 0, 0, NULL, uuid); +} + +int do_xfs_admin (const char *device, int extunwritten, int imgfile, int v2log, int projid32bit, -- 2.1.0

...t char *device, const char *uuid) } int +xfs_set_uuid_random (const char *device) +{ + optargs_bitmask = GUESTFS_XFS_ADMIN_UUID_BITMASK; + return do_xfs_admin (device, 0, 0, 0, 0, 0, NULL, "generate"); +} + +int do_xfs_admin (const char *device, int extunwritten, int imgfile, int v2log, int projid32bit, -- 2.1.0

...S, also require different versions of kernel.sys.) 3) newmkfloppyimg.sh doesn't show the output from mkdosfs, so you won't know whether the file system changed. 4) After-the-fact, you can determine whether two images have the same underlying file system type by running "dosfsck -V imgfile" and looking for the number in front of "bit entries". 5) Or look inside newmkfloppyimg.sh and run mkdosfs manually to look at all the output for clues as to what was created. 6) To eliminate a change in filesystem, you can change the parameters that newmkfloppyimg.sh passes to...

...t char *device, const char *uuid) } int +xfs_set_uuid_random (const char *device) +{ + optargs_bitmask = GUESTFS_XFS_ADMIN_UUID_BITMASK; + return do_xfs_admin (device, 0, 0, 0, 0, 0, NULL, "generate"); +} + +int do_xfs_admin (const char *device, int extunwritten, int imgfile, int v2log, int projid32bit, diff --git a/generator/actions.ml b/generator/actions.ml index b1865e0..b214c37 100644 --- a/generator/actions.ml +++ b/generator/actions.ml @@ -12636,6 +12636,22 @@ removed from the filesystem. The C<targetdev> needs to be same size or larger tha...

- Btrfs-progs v4.1 introduced new feature of changing uuid of btrfs partition. This patch add support of this. - Introduce set_uuid_random - uuids.c did a lot of deplicated work for changing uuid of fs. Use existing functions. v4: introduce get_random_uuid improve testcases squash internal API patches v3.1: fix typos v3: set errno if feature is not available. Chen Hanxiao (7):

- Btrfs-progs v4.1 introduced new feature of changing uuid of btrfs partition. This patch add support of this. - Introduce set_uuid_random - uuids.c did a lot of deplicated work for changing uuid of fs. Use existing functions. v5: use NOT_SUPPORTED macro improve testcases v4: introduce get_random_uuid improve testcases squash internal API patches v3.1: fix typos v3: set errno