-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Milkowski wrote:
> CG> Yes, it is Sun's cp. I'm trying, with some difficulty, to figure out
> CG> exactly how to reproduce this error in a way not specific to my data. I
> CG> copied a set of randomly generated files with a deep directory str
[EMAIL PROTECTED] wrote:
>
>
> >Also, from my _very limited_ investigation this morning, it seems tha=
> >t
> >#grep Err /tmp/getdents.bin.cp.truss | grep -v ENOENT | grep getdents
> >
> >returns entries such as:
> >getdents64(0, 0xFEC92000, 8192) Err#9 EBADF
> >getdents64(0, 0xFEC
Hello Joerg,
Wednesday, January 30, 2008, 2:56:27 PM, you wrote:
JS> Robert Milkowski <[EMAIL PROTECTED]> wrote:
>> If you could re-create empty files - exactly the same directory
>> atructure and file names, check if you still got a problem.
>> If you do, then if you could send a script here (m
>Also, from my _very limited_ investigation this morning, it seems tha=
>t
>#grep Err /tmp/getdents.bin.cp.truss | grep -v ENOENT | grep getdents
>
>returns entries such as:
>getdents64(0, 0xFEC92000, 8192) Err#9 EBADF
>getdents64(0, 0xFEC92000, 8192) Err#9 EBADF
>
Robert Milkowski <[EMAIL PROTECTED]> wrote:
> If you could re-create empty files - exactly the same directory
> atructure and file names, check if you still got a problem.
> If you do, then if you could send a script here (mkdir's -p and touch)
> so we can investigate.
If you like to replicate a
Christopher Gorski <[EMAIL PROTECTED]> wrote:
> I am able to replicate the problem in bash using:
> #truss -tall -vall -o /tmp/getdents.bin.cp.truss /bin/cp -pr
> /pond/photos/* /pond/copytestsame/
>
> So I'm assuming that's using /bin/cp
>
> Also, from my _very limited_ investigation this morning
Hello Christopher,
Wednesday, January 30, 2008, 7:27:01 AM, you wrote:
CG> Carson Gaspar wrote:
>> Christopher Gorski wrote:
>>
>>> I noticed that the first calls in the "cp" and "ls" to getdents() return
>>> similar file lists, with the same values.
>>>
>>> However, in the "ls", it makes a sec
Joerg Schilling wrote:
> "Will Murnane" <[EMAIL PROTECTED]> wrote:
>
>> On Jan 30, 2008 1:34 AM, Carson Gaspar <[EMAIL PROTECTED]> wrote:
>>> If this is Sun's cp, file a bug. It's failing to notice that it didn't
>>> provide a large enough buffer to getdents(), so it only got partial results.
>>>
[EMAIL PROTECTED] wrote:
> And "ls" would fail in the same manner.
>
>
> There's one piece of code in "cp" (see usr/src/cmd/mv/mv.c) which
> short-circuits a readdir-loop:
>
> while ((dp = readdir(srcdirp)) != NULL) {
> int ret;
>
> if ((ret = traverse_attr
"Will Murnane" <[EMAIL PROTECTED]> wrote:
> On Jan 30, 2008 1:34 AM, Carson Gaspar <[EMAIL PROTECTED]> wrote:
> > If this is Sun's cp, file a bug. It's failing to notice that it didn't
> > provide a large enough buffer to getdents(), so it only got partial results.
> >
> > Of course, the getdents(
Christopher Gorski <[EMAIL PROTECTED]> wrote:
> > Of course, the getdents() API is rather unfortunate. It appears the only
> > safe algorithm is:
> >
> > while ((r = getdents(...)) > 0) {
> > /* process results */
> > }
> > if (r < 0) {
> > /* handle error */
> > }
> >
> > You _always_
>That code appears to error out and return incomplete results if a) the
>filename is too long or b) an integer overflows. Christopher's
>filenames are only 96 chars; could Unicode be involved somehow? b)
>seems unlikely in the extreme. It still seems like a bug, but I don't
>see where it is.
>Christopher Gorski wrote:
>
>> I noticed that the first calls in the "cp" and "ls" to getdents() return
>> similar file lists, with the same values.
>>
>> However, in the "ls", it makes a second call to getdents():
>
>If this is Sun's cp, file a bug. It's failing to notice that it didn't
>prov
On Jan 30, 2008 1:34 AM, Carson Gaspar <[EMAIL PROTECTED]> wrote:
> If this is Sun's cp, file a bug. It's failing to notice that it didn't
> provide a large enough buffer to getdents(), so it only got partial results.
>
> Of course, the getdents() API is rather unfortunate. It appears the only
> sa
Carson Gaspar wrote:
> Christopher Gorski wrote:
>
>> I noticed that the first calls in the "cp" and "ls" to getdents() return
>> similar file lists, with the same values.
>>
>> However, in the "ls", it makes a second call to getdents():
>
> If this is Sun's cp, file a bug. It's failing to notic
Christopher Gorski wrote:
> I noticed that the first calls in the "cp" and "ls" to getdents() return
> similar file lists, with the same values.
>
> However, in the "ls", it makes a second call to getdents():
If this is Sun's cp, file a bug. It's failing to notice that it didn't
provide a larg
Christopher Gorski wrote:
> Christopher Gorski wrote:
>> Robert Milkowski wrote:
>>> As Joerg suggested - please check getdents() - remember to use truss
>>> -v getdents so you should see all directory listings.
>>>
>>> I would check both getdents and open - so if it appears in getdents
>>>
Christopher Gorski wrote:
> Robert Milkowski wrote:
>>
>> As Joerg suggested - please check getdents() - remember to use truss
>> -v getdents so you should see all directory listings.
>>
>> I would check both getdents and open - so if it appears in getdents
>> but is not opened later on...
>>
>>
>
Robert Milkowski wrote:
>
>
> As Joerg suggested - please check getdents() - remember to use truss
> -v getdents so you should see all directory listings.
>
> I would check both getdents and open - so if it appears in getdents
> but is not opened later on...
>
>
I ran the copy procedure with
On Tue, 29 Jan 2008 14:25:18 +0200
Marcus Sundman <[EMAIL PROTECTED]> wrote:
> Mark Ashley <[EMAIL PROTECTED]> wrote:
>> It's simply a shell grokking issue, when you allow your
>>(l)users to
>> self name your files then you will have spaces etc in
>>the filename
>> (breaks shell arguments). In
Mark Ashley <[EMAIL PROTECTED]> wrote:
> It's simply a shell grokking issue, when you allow your (l)users to
> self name your files then you will have spaces etc in the filename
> (breaks shell arguments). In this case the '[E]' is breaking your
> command line argument grokking.
Can't be, because
It's simply a shell grokking issue, when you allow your (l)users to self
name your files then you will have spaces etc in the filename (breaks
shell arguments). In this case the '[E]' is breaking your command line
argument grokking. We have the same issue in our photos tree. We have to
use non
Hello Christopher,
Friday, January 25, 2008, 5:49:14 PM, you wrote:
CG> Robert Milkowski wrote:
>> Hello Christopher,
>>
>> Friday, January 25, 2008, 5:37:58 AM, you wrote:
>>
>> CG> michael schuster wrote:
I assume you've assured that there's enough space in /pond ...
can you tr
On Fri, 25 Jan 2008 15:18:36 -0500
"Tiernan, Daniel" <[EMAIL PROTECTED]>
wrote:
>
> You may have hit a cp and or shell bug due to the
>directory naming
> topology. Rather then depend on cp -r I prefer the cpio
>method:
>
> find * print|cpio -pdumv dest_path
>
> I'd try the find by itself to
Christopher Gorski <[EMAIL PROTECTED]> wrote:
> >>> can you try
> >>>
> >>> $(cd pond/photos; tar cf - *) | (cd /pond/copytestsame; tar xf -)
> >
> > CG> I tried it, and it worked. The new tree is an exact copy of the old
> > one.
> >
> > could you run your cp as 'truss -t open -o /tmp/cp.trus
ssage-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Gorski
Sent: Friday, January 25, 2008 12:52 PM
To: Robert Milkowski
Cc: zfs-discuss@opensolaris.org; michael schuster
Subject: Re: [zfs-discuss] missing files on copy
Christopher Gorski wrote:
> "unsorted
Christopher Gorski wrote:
> "unsorted/photosbackup/laptopd600/[D]/cag2b/eujpg/103-0398_IMG.JPG" is a
> file that is always missing in the new tree.
Oops, I meant:
"unsorted/drive-452a/[E]/drive/archives/seconddisk_20nov2002/eujpg/103-0398_IMG.JPG"
is always missing in the new tree.
__
Robert Milkowski wrote:
> Hello Christopher,
>
> Friday, January 25, 2008, 5:37:58 AM, you wrote:
>
> CG> michael schuster wrote:
>>> I assume you've assured that there's enough space in /pond ...
>>>
>>> can you try
>>>
>>> $(cd pond/photos; tar cf - *) | (cd /pond/copytestsame; tar xf -)
>
> C
Hello Christopher,
Friday, January 25, 2008, 5:37:58 AM, you wrote:
CG> michael schuster wrote:
>>
>> I assume you've assured that there's enough space in /pond ...
>>
>> can you try
>>
>> $(cd pond/photos; tar cf - *) | (cd /pond/copytestsame; tar xf -)
CG> I tried it, and it worked. The ne
michael schuster wrote:
>
> I assume you've assured that there's enough space in /pond ...
>
> can you try
>
> $(cd pond/photos; tar cf - *) | (cd /pond/copytestsame; tar xf -)
I tried it, and it worked. The new tree is an exact copy of the old one.
-Chris
___
Nicolas Williams wrote:
> Are there so many files that the glob expansion results in too large an
> argument list for cp?
There are only four subdirs in /pond/photos:
# ls /pond/photos
2006-02-15 2006-06-09 2007-12-20 unsorted
___
zfs-discuss maili
Are there so many files that the glob expansion results in too large an
argument list for cp?
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
No. Here's a cut and paste of names of actual files missing:
(the original)
ls -al
/pond/photos/unsorted/drive-452a/\[E\]/drive/archives/seconddisk_20nov2002/eujpg/103-0*
-rwxr--r-- 1 root root 593558 Nov 20 2002
/pond/photos/unsorted/drive-452a/[E]/drive/archives/seconddisk_20nov20
Nicolas Williams wrote:
> On Thu, Jan 24, 2008 at 11:06:13PM -0500, Christopher Gorski wrote:
>> I'm missing actual files.
>>
>>> Christopher Gorski wrote:
zfs create pond/read-only
mkdir /pond/read-only/copytest
cp -rp /pond/photos/* /pond/read-only/copytest/
>
> Might the missing
On Thu, Jan 24, 2008 at 11:06:13PM -0500, Christopher Gorski wrote:
> I'm missing actual files.
>
> > Christopher Gorski wrote:
> >> zfs create pond/read-only
> >> mkdir /pond/read-only/copytest
> >> cp -rp /pond/photos/* /pond/read-only/copytest/
Might the missing files' names start with '.' by
Christopher Gorski wrote:
> FWIW, I just finished performing a copy again, to the same filesystem:
>
> mkdir /pond/copytestsame
> cd /pond/photos
> cp -rp * /pond/copytestsame
>
> Same files are missing throughout the new tree...on the order of a
> thousand files. There are about 27k files in /p
FWIW, I just finished performing a copy again, to the same filesystem:
mkdir /pond/copytestsame
cd /pond/photos
cp -rp * /pond/copytestsame
Same files are missing throughout the new tree...on the order of a
thousand files. There are about 27k files in /pond/photos and 25k files
in /pond/copytest
I'm missing actual files.
I did this a second time, with the exact same result. It appears that
the missing files in each copy are the same files.
I originally copied these files over via Samba before trying to copy
them locally with cp to the other file system.
I'll have 200 sequentially numbe
Christopher Gorski wrote:
> Hi, I'm running snv_78 on a dual-core 64-bit x86 system with 2 500GB usb
> drives mirrored into one pool.
>
> I did this (intending to set the rdonly flag after I copy my data):
>
> zfs create pond/read-only
> mkdir /pond/read-only/copytest
> cp -rp /pond/photos/* /pon
Hi, I'm running snv_78 on a dual-core 64-bit x86 system with 2 500GB usb
drives mirrored into one pool.
I did this (intending to set the rdonly flag after I copy my data):
zfs create pond/read-only
mkdir /pond/read-only/copytest
cp -rp /pond/photos/* /pond/read-only/copytest/
After the copy is c
40 matches
Mail list logo
