From bhudspeth at edac.unm.edu Wed Jan 5 02:38:27 2011 From: bhudspeth at edac.unm.edu (William Hudspeth, Ph.D.) Date: Tue, 04 Jan 2011 19:38:27 -0700 Subject: Place of Django template tags inside of ext3.0 viewport panels Message-ID: <1294195107.3072.4.camel@dell-desktop.example.com> Hello, Does anyone know where I can find information on using ext3 with Django. Specifically, I want to place Django template tags inside of a particular panel in my ext3 viewport... I have tried what is seen below, but it doesn't seem to work.. var viewport=new Ext.Panel({ layout: 'border', width:1200, height:650, renderTo: Ext.getBody(), items: [{ region: 'north', xtype: 'panel', layout: 'fit', --------------> html:{% placeholder base_content %}, width:1200, height:50, },{ region: 'center', .... .... ... Thanks, Bill From listudo at bestsolution.at Wed Jan 5 08:22:30 2011 From: listudo at bestsolution.at (Udo Rader) Date: Wed, 05 Jan 2011 09:22:30 +0100 Subject: Place of Django template tags inside of ext3.0 viewport panels In-Reply-To: <1294195107.3072.4.camel@dell-desktop.example.com> References: <1294195107.3072.4.camel@dell-desktop.example.com> Message-ID: <4D242A46.9080904@bestsolution.at> On 01/05/2011 03:38 AM, William Hudspeth, Ph.D. wrote: > Does anyone know where I can find information on using ext3 with Django. > Specifically, I want to place Django template tags inside of a > particular panel in my ext3 viewport... I have tried what is seen below, > but it doesn't seem to work.. > > var viewport=new Ext.Panel({ > layout: 'border', > width:1200, > height:650, > renderTo: Ext.getBody(), > items: [{ > region: 'north', > xtype: 'panel', > layout: 'fit', > --------------> html:{% placeholder base_content %}, > width:1200, > height:50, > },{ > region: 'center', I think what you first need is to understand what ext3 [1] and this list is about and then refine your query. [1] http://en.wikipedia.org/wiki/Ext3 -- Udo Rader, CTO http://www.bestsolution.at http://riaschissl.blogspot.com From lakshmipathi.g at gmail.com Tue Jan 18 09:55:15 2011 From: lakshmipathi.g at gmail.com (Lakshmipathi.G) Date: Tue, 18 Jan 2011 15:25:15 +0530 Subject: How to remove extended attribute from file ? Message-ID: Hi - I need to check two syscalls from command line/shell setxattr() and removeattr() with ext4fs. I have used the command setfattr "setfattr -n user.foo -v bar file.txt" to set extended attribute to a file. Do we have a command (like removefattr) which calls removexattr() ? -- ---- Cheers, Lakshmipathi.G FOSS Programmer. www.giis.co.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From lakshmipathi.g at gmail.com Tue Jan 18 10:01:39 2011 From: lakshmipathi.g at gmail.com (Lakshmipathi.G) Date: Tue, 18 Jan 2011 15:31:39 +0530 Subject: How to remove extended attribute from file ? In-Reply-To: References: Message-ID: Got it "setfattr -x" . On Tue, Jan 18, 2011 at 3:25 PM, Lakshmipathi.G wrote: > Hi - > I need to check two syscalls from command line/shell setxattr() and > removeattr() with ext4fs. > > I have used the command setfattr "setfattr -n user.foo -v bar file.txt" > to set extended attribute to a file. > Do we have a command (like removefattr) which calls removexattr() ? > > -- > ---- > Cheers, > Lakshmipathi.G > FOSS Programmer. > www.giis.co.in > -- ---- Cheers, Lakshmipathi.G FOSS Programmer. www.giis.co.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ralf.Hildebrandt at charite.de Tue Jan 18 13:39:44 2011 From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt) Date: Tue, 18 Jan 2011 14:39:44 +0100 Subject: ext4 online defrag status Message-ID: <20110118133944.GO24779@charite.de> So I googled the $TOPIC, I checked the archives (just to find old stuff dating back 1-2 years). I also read "Thoughts by Ted" and think that Nokia is indeed doomed. But no word about the defrag status :) -- Ralf Hildebrandt Gesch?ftsbereich IT | Abteilung Netzwerk Charit? - Universit?tsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt at charite.de | http://www.charite.de From martin at ebcl.lib.id.us Fri Jan 21 18:36:41 2011 From: martin at ebcl.lib.id.us (m.p.) Date: Fri, 21 Jan 2011 10:36:41 -0800 Subject: recovery recommendations Message-ID: <1295635001.23452.10.camel@gallylayoh> Recently a 640GB external enclosure was PEBKAC'd with the following command: dd if=/some-185mb-linux-install.iso of=/dev/sdx [not of=/dev/sdx1] Since the PEBKAC, the drive has not been written to beyond being unplugged. I have made an image of the drive and have attempted to run against it: testdisk, fsck.ext3 with alternate superblocks, and even "fsck.ext3 -Sy", to no avail. So. I am *convinced* that my 550gb of data is recoverable. It seems that [obviously] the first 185mb is gone - whatever files those were. I have googled, but to be honest, I am not entirely sure I'm searching the right strings. Most software seems geared towards partition recovery where a partition has become damaged [which is technically what's happened], but not exactly; or partition undeleting [which again isn't technically what happened]. Please, any recommendations that don't involve a time machine are much appreciated. If this isn't the place to be asking, please point me in the right direction. Thank you. -mp- - kicking self - From sandeen at redhat.com Fri Jan 21 19:06:05 2011 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 21 Jan 2011 13:06:05 -0600 Subject: recovery recommendations In-Reply-To: <1295635001.23452.10.camel@gallylayoh> References: <1295635001.23452.10.camel@gallylayoh> Message-ID: <4D39D91D.5010100@redhat.com> On 1/21/11 12:36 PM, m.p. wrote: > Recently a 640GB external enclosure was PEBKAC'd with the following > command: > > dd if=/some-185mb-linux-install.iso of=/dev/sdx > > [not of=/dev/sdx1] > > Since the PEBKAC, the drive has not been written to beyond being > unplugged. I have made an image of the drive and have attempted to run > against it: testdisk, fsck.ext3 with alternate superblocks, and even > "fsck.ext3 -Sy", to no avail. > > So. I am *convinced* that my 550gb of data is recoverable. It seems that > [obviously] the first 185mb is gone - whatever files those were. You really need to restore from backups. You just overwrote 30% of your filesystem with something else... you've lost partition data, metadata, directory data, file data ... whatever was in that first 185M. I think the best you can do is low-level recovery at this point, groveling around for file fragments with something like the photo recovery tools. > I have googled, but to be honest, I am not entirely sure I'm searching > the right strings. Most software seems geared towards partition recovery > where a partition has become damaged [which is technically what's > happened], You've done much more than that... > but not exactly; or partition undeleting [which again isn't > technically what happened]. > > Please, any recommendations that don't involve a time machine are much > appreciated. Maybe, just -maybe- if you can find a backup superblock, fsck might try to piece a few things together. But you can't generally overwrite 1/3 of a filesystem and expect normal tools to recover for you, I'm afraid. -Eric > If this isn't the place to be asking, please point me in the right > direction. > > Thank you. > > -mp- - kicking self - > > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users From alex at alex.org.uk Fri Jan 21 19:16:54 2011 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 21 Jan 2011 19:16:54 +0000 Subject: recovery recommendations In-Reply-To: <1295635001.23452.10.camel@gallylayoh> References: <1295635001.23452.10.camel@gallylayoh> Message-ID: <0D0A0C757C681C8A42907393@Ximines.local> --On 21 January 2011 10:36:41 -0800 "m.p." wrote: > dd if=/some-185mb-linux-install.iso of=/dev/sdx You wrote to /dev/sdx not /dev/sdxN (where N is a number)? You will have zapped your partition table. If you only had one partition on there, you can recreate this by running fdisk on the image first. Note ext3 recovery tools want a partition image, not a disk image. You can use dd with the appropriate skip (or use sparsecopy from http://blog.alex.org.uk/2010/12/02/copying-sparse-files/ ) to get the partition out from the disk image. -- Alex Bligh From adilger at dilger.ca Fri Jan 21 20:05:13 2011 From: adilger at dilger.ca (Andreas Dilger) Date: Fri, 21 Jan 2011 13:05:13 -0700 Subject: recovery recommendations In-Reply-To: <4D39D91D.5010100@redhat.com> References: <1295635001.23452.10.camel@gallylayoh> <4D39D91D.5010100@redhat.com> Message-ID: <50F3AE32-891C-448F-9AFF-9E700ACD86DC@dilger.ca> On 2011-01-21, at 12:06, Eric Sandeen wrote: > On 1/21/11 12:36 PM, m.p. wrote: >> Recently a 640GB external enclosure was PEBKAC'd with the following >> command: >> >> dd if=/some-185mb-linux-install.iso of=/dev/sdx >> >> [not of=/dev/sdx1] >> >> Since the PEBKAC, the drive has not been written to beyond being >> unplugged. I have made an image of the drive and have attempted to run >> against it: testdisk, fsck.ext3 with alternate superblocks, and even >> "fsck.ext3 -Sy", to no avail. >> >> So. I am *convinced* that my 550gb of data is recoverable. It seems that >> [obviously] the first 185mb is gone - whatever files those were. > > You really need to restore from backups. You just overwrote 30% of > your filesystem with something else... you've lost partition data, > metadata, directory data, file data ... whatever was in that first > 185M. Eric, note 185 Megabytes, vs 550 Gigabytes, so only the first 1.5 groups were clobbered (which may have been largely filled by the journal, depending on when the filesystem was formatted). > I think the best you can do is low-level recovery at this point, > groveling around for file fragments with something like the photo recovery > tools. Actually, I think the chance for significant data recovery is pretty good. > Maybe, just -maybe- if you can find a backup superblock, fsck might try > to piece a few things together. I think the first thing to do is to recover the partition table EXACTLY the way it was before. There was a tool for this, "gpart" or something similar, that could recover partition tables. Alternately, if you build and run the "findsuper" tool from e2fsprogs sources (I've attached an x86_64 binary here, maybe it will work for you), it will tell you the starting and ending offset of each ext* filesystem, based on superblocks that it finds on the disk. You need to take the byte offsets and convert them into kB or sector offsets for use with fdisk. Once you get the partition table correct, e2fsck should have no problem to recover the filesystem, though it will be missing the root directory and possibly a bunch of other files that were stored in the first 185MB of disk. The possibly good news is that the journal _used_ to be stored at the start of the filesystem, and would fill 32MB or 128MB of the start of the disk, and in turn that dissuaded the allocator from putting files into that group. Sadly (maybe), the journal is now allocated in the middle of the filesystem for performance reasons and that coincidental "data protection" is no longer with us. > But you can't generally overwrite 1/3 of a filesystem and expect normal > tools to recover for you, I'm afraid. Surprisingly, extN is very robust in this regard. I've been able (required) to recover data from similarly corrupted filesystems, and a lot can be done. With changes like flex_bg and UNMAP it will get a lot harder, however. Cheers, Andreas From sandeen at redhat.com Fri Jan 21 20:09:19 2011 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 21 Jan 2011 14:09:19 -0600 Subject: recovery recommendations In-Reply-To: <50F3AE32-891C-448F-9AFF-9E700ACD86DC@dilger.ca> References: <1295635001.23452.10.camel@gallylayoh> <4D39D91D.5010100@redhat.com> <50F3AE32-891C-448F-9AFF-9E700ACD86DC@dilger.ca> Message-ID: <4D39E7EF.5010008@redhat.com> On 1/21/11 2:05 PM, Andreas Dilger wrote: > On 2011-01-21, at 12:06, Eric Sandeen wrote: >> On 1/21/11 12:36 PM, m.p. wrote: >>> Recently a 640GB external enclosure was PEBKAC'd with the >>> following command: >>> >>> dd if=/some-185mb-linux-install.iso of=/dev/sdx >>> >>> [not of=/dev/sdx1] >>> >>> Since the PEBKAC, the drive has not been written to beyond being >>> unplugged. I have made an image of the drive and have attempted >>> to run against it: testdisk, fsck.ext3 with alternate >>> superblocks, and even "fsck.ext3 -Sy", to no avail. >>> >>> So. I am *convinced* that my 550gb of data is recoverable. It >>> seems that [obviously] the first 185mb is gone - whatever files >>> those were. >> >> You really need to restore from backups. You just overwrote 30% >> of your filesystem with something else... you've lost partition >> data, metadata, directory data, file data ... whatever was in that >> first 185M. > > Eric, note 185 Megabytes, vs 550 Gigabytes, so only the first 1.5 > groups were clobbered (which may have been largely filled by the > journal, depending on when the filesystem was formatted). Oops sorry, my old physics teacher would not be proud: "think units before you think numbers" he said... So ignore what I said, and listen to Andreas. Sorry about that! -Eric >> I think the best you can do is low-level recovery at this point, >> groveling around for file fragments with something like the photo >> recovery tools. > > Actually, I think the chance for significant data recovery is pretty > good. > >> Maybe, just -maybe- if you can find a backup superblock, fsck might >> try to piece a few things together. > > I think the first thing to do is to recover the partition table > EXACTLY the way it was before. There was a tool for this, "gpart" or > something similar, that could recover partition tables. > > Alternately, if you build and run the "findsuper" tool from e2fsprogs > sources (I've attached an x86_64 binary here, maybe it will work for > you), it will tell you the starting and ending offset of each ext* > filesystem, based on superblocks that it finds on the disk. You need > to take the byte offsets and convert them into kB or sector offsets > for use with fdisk. > > Once you get the partition table correct, e2fsck should have no > problem to recover the filesystem, though it will be missing the root > directory and possibly a bunch of other files that were stored in the > first 185MB of disk. The possibly good news is that the journal > _used_ to be stored at the start of the filesystem, and would fill > 32MB or 128MB of the start of the disk, and in turn that dissuaded > the allocator from putting files into that group. Sadly (maybe), the > journal is now allocated in the middle of the filesystem for > performance reasons and that coincidental "data protection" is no > longer with us. > >> But you can't generally overwrite 1/3 of a filesystem and expect >> normal tools to recover for you, I'm afraid. > > Surprisingly, extN is very robust in this regard. I've been able > (required) to recover data from similarly corrupted filesystems, and > a lot can be done. With changes like flex_bg and UNMAP it will get a > lot harder, however. > > > Cheers, Andreas > > > > > From Florian.Weber at pfaffenhofen.de Fri Jan 21 21:51:20 2011 From: Florian.Weber at pfaffenhofen.de (Florian Weber) Date: Fri, 21 Jan 2011 22:51:20 +0100 Subject: recovery recommendations In-Reply-To: <1295635001.23452.10.camel@gallylayoh> References: <1295635001.23452.10.camel@gallylayoh> Message-ID: <201101212251.26007.Florian.Weber@pfaffenhofen.de> Hello m.p. On Friday 21 January 2011 19:36:41 m.p. wrote: > Recently a 640GB external enclosure was PEBKAC'd with the following > command: A short time ago I overwrote the first 12GB of my single-disk 1TB system. Thise 12GB luckily contained only OS files I was about to replace anyway (still gotta write that up as solved; see the archives for "Overwritten beginning of ext3 filesystem. Recovery?" on 27dec2010). I got all my important user data back in one piece. Depending on usage patterns and the kind of data you had on that disk, I think your chances are pretty good to get most of it back. > So. I am *convinced* that my 550gb of data is recoverable. It seems that > [obviously] the first 185mb is gone - whatever files those were. In my case, I overwrote an ext3 partition's first few GB with a valid ext3 FS of identical size but different content. fsck then found lots of errors (in the "overlaying" FS) due to it being incomplete. The problems were so bad that it never actually got to recovering the good ("underlaying") data. What did the trick for me was to zero out the offending stuff. In your case that would be sth. like: * Keep a copy of your "unrecovered" disk image! You don't want to touch the original disk at all, so be prepared for making mistakes * dd if=/dev/zero of=PARTIMAGE count=ISOSIZE where ISOSIZE is the ISO image's size in bytes * Extract the partition image like Alex Bligh wrote and work with that * e2fsck -f -y /dev/sdx1 (perhaps -b and -C0 as well) e2fsck will probably ask you to be run again (might want do that anyway to make sure) You'll then find the remainder of your data in lost+found/, even most directory hierarchies will be intact. Some pretty much random(!) data blocks from seemingly anywhere(!) on disk will be zeroed out, but at least those will be easily recognizable. The exact outcome depends on what data you had on there, as well as usage scenario and history. It's imperative that you check every file of the results - any data block might be missing, any subdirectory might be missing. If you lost a directory entry, chances are high that it's contents will show up directly (and namelessly) in lost+found/. Hope that helps. If you find the time, please keep me posted about your results. -- With best regards, Florian Weber From martin at ebcl.lib.id.us Sat Jan 22 00:12:46 2011 From: martin at ebcl.lib.id.us (m.p.) Date: Fri, 21 Jan 2011 16:12:46 -0800 Subject: recovery recommendations Message-ID: <1295655166.2900.6.camel@gallylayoh> All, Thank you *very* much for the salient & encouraging suggestions. The usage of the drive is/was purely storage - stuffed inside an external enclosure. I will keep those interested parties apprised of any developments - it will likely be several days - it took over 40 hours just to image the murder-victim > rescue-drive. And later on, I will submit to all the "where was your backup?" you care to inflict. :) For now, it's too much agony. Thirty years worth of scanned family fotos [among other irreplaceables] hang in the balance - you know the drill. It's *never* the drive full of Robot Chicken episodes that gets nuked .... -m- From alex at alex.org.uk Sat Jan 22 08:28:35 2011 From: alex at alex.org.uk (Alex Bligh) Date: Sat, 22 Jan 2011 08:28:35 +0000 Subject: recovery recommendations In-Reply-To: <1295655166.2900.6.camel@gallylayoh> References: <1295655166.2900.6.camel@gallylayoh> Message-ID: --On 21 January 2011 16:12:46 -0800 "m.p." wrote: > Thirty years worth of > scanned family fotos [among other irreplaceables] hang in the balance - > you know the drill. I've had 100% success getting photos back with PhotoRec which doesn't rely on metadata. -- Alex Bligh From mnalis-ml at voyager.hr Sat Jan 22 13:57:21 2011 From: mnalis-ml at voyager.hr (Matija Nalis) Date: Sat, 22 Jan 2011 14:57:21 +0100 Subject: recovery recommendations In-Reply-To: <201101212251.26007.Florian.Weber@pfaffenhofen.de> References: <1295635001.23452.10.camel@gallylayoh> <201101212251.26007.Florian.Weber@pfaffenhofen.de> Message-ID: <20110122135721.GA8678@eagle102.home.lan> On Fri, Jan 21, 2011 at 10:51:20PM +0100, Florian Weber wrote: > * Keep a copy of your "unrecovered" disk image! You don't want to touch the > original disk at all, so be prepared for making mistakes yes, that is always the most important step. And be extra extra carefull you don't nuke it by accident... readonly jumper on the drive (if it has one) helps. > * dd if=/dev/zero of=PARTIMAGE count=ISOSIZE > where ISOSIZE is the ISO image's size in bytes actually, it is ISO image size in *blocks* [1], so this procedure would actually destroy 512 times more data than original error... :-| Anyway, let us know how it worked out... And if this procedure fails you, I'd also second the great experiences with http://www.cgsecurity.org/wiki/PhotoRec - works even if filesystem and partition structures are completely foobared... If you use it and it works for you, don't forget to donate to the guy, there's link on the pages. [1] by default block size is 512 bytes, can be changed with bs= parametar to dd(1) -- note that while you can use 1 byte as an unit, it will be terribly slow; so it is probably best to use let's say bs=4K, divide ISOSIZE in bytes by 4096, round it down to nearest integer, and use that as count= parameter. -- Opinions above are GNU-copylefted. From samuel at bcgreen.com Sat Jan 22 21:00:32 2011 From: samuel at bcgreen.com (Stephen Samuel) Date: Sat, 22 Jan 2011 13:00:32 -0800 Subject: recovery recommendations In-Reply-To: <20110122135721.GA8678@eagle102.home.lan> References: <1295635001.23452.10.camel@gallylayoh> <201101212251.26007.Florian.Weber@pfaffenhofen.de> <20110122135721.GA8678@eagle102.home.lan> Message-ID: A simple one would be: dd if=/dev/zero of=PARTIMAGE bs=1M count=184 (presuming that your original ISO was 185MB. -- this leaves up to 1MB of random crap, but (in my mind), that's better than tashing the good bits of data. You can get more accurate results by varying the block size and the count so that they multiply out properly. modern versions of DD recognize multipliers of K -> kilobytes, M->Megabytes, G->gigabytes .. and those are the CS units (now called kibibytes, mebibytes, gibibytes), not the marketing units. On Sat, Jan 22, 2011 at 5:57 AM, Matija Nalis wrote: > On Fri, Jan 21, 2011 at 10:51:20PM +0100, Florian Weber wrote: > > * Keep a copy of your "unrecovered" disk image! You don't want to touch > the > > original disk at all, so be prepared for making mistakes > > yes, that is always the most important step. And be extra extra carefull > you > don't nuke it by accident... readonly jumper on the drive (if it has one) > helps. > > > * dd if=/dev/zero of=PARTIMAGE count=ISOSIZE > > where ISOSIZE is the ISO image's size in bytes > > actually, it is ISO image size in *blocks* [1], so this procedure would > actually destroy 512 times more data than original error... :-| > > Anyway, let us know how it worked out... > > And if this procedure fails you, I'd also second the great experiences with > http://www.cgsecurity.org/wiki/PhotoRec - works even if filesystem and > partition structures are completely foobared... If you use it and it works > for you, don't forget to donate to the guy, there's link on the pages. > > [1] by default block size is 512 bytes, can be changed with bs= parametar > to > dd(1) -- note that while you can use 1 byte as an unit, it will be > terribly > slow; so it is probably best to use let's say bs=4K, divide ISOSIZE in > bytes > by 4096, round it down to nearest integer, and use that as count= > parameter. > > -- > Opinions above are GNU-copylefted. > > _______________________________________________ > Ext3-users mailing list > Ext3-users at redhat.com > https://www.redhat.com/mailman/listinfo/ext3-users > -- Stephen Samuel http://www.bcgreen.com Software, like love, 778-861-7641 grows when you give it away -------------- next part -------------- An HTML attachment was scrubbed... URL: From Florian.Weber at pfaffenhofen.de Sun Jan 23 16:52:43 2011 From: Florian.Weber at pfaffenhofen.de (Florian Weber) Date: Sun, 23 Jan 2011 17:52:43 +0100 Subject: recovery recommendations In-Reply-To: <20110122135721.GA8678@eagle102.home.lan> References: <1295635001.23452.10.camel@gallylayoh> <201101212251.26007.Florian.Weber@pfaffenhofen.de> <20110122135721.GA8678@eagle102.home.lan> Message-ID: <201101231752.46532.Florian.Weber@pfaffenhofen.de> On Saturday 22 January 2011 14:57:21 Matija Nalis wrote: > > * dd if=/dev/zero of=PARTIMAGE count=ISOSIZE > > where ISOSIZE is the ISO image's size in bytes > actually, it is ISO image size in *blocks* [1] I stand corrected and am ashamed. Luckily, the 'net will catch such stupidity quickly - thanks Matija! Florian Weber From tushu1232 at gmail.com Thu Jan 27 04:31:03 2011 From: tushu1232 at gmail.com (tushu1232 at gmail.com) Date: Thu, 27 Jan 2011 00:31:03 -0400 (AST) Subject: thinks you should join SoSasta! Message-ID: <20110127043103.18BC615F8066@ip-72-167-245-7.ip.secureserver.net> An HTML attachment was scrubbed... URL: From shivraj198 at gmail.com Thu Jan 13 09:26:44 2011 From: shivraj198 at gmail.com (shivraj) Date: Thu, 13 Jan 2011 09:26:44 -0000 Subject: mount problems with ext3 Message-ID: <30660579.post@talk.nabble.com> dear all , i have created ext3 partition on NetBSD system i am sending data to that ext3 partition using iscsi protocol. i have mounted the same partition on another linux machine . The problem is that to view new upcomming data on ext3 partition i need to first umount and then need to mount the previously mounted partition. can any one tell me whether i can view new data on the ext3 partition without unmounting and mounting that partition? -- View this message in context: http://old.nabble.com/mount-problems-with-ext3-tp30660579p30660579.html Sent from the Ext3 - User mailing list archive at Nabble.com.