| Author |
Message |
William K Rankine
Guest
|
 Posted:
Tue Jul 12, 2005 4:51 pm Post subject:
PDF filetype not replicating |
|
|
What can stop DFS / FRS replicating a particular type of file?
We use PDF995 to create PDFs of Word documents, CAD drawings and so
on. No PDF cerated by PDF995 will replicate. No error, it just sits
there.
If we use Adobe Acrobat to crate the PDF, it is replicated.
We've tried creating with PDF with PDF995 to a local hard disk then
copying it to the folder being replicated (in case it was an odd
locking issue). We've disabled content indexing (which was using
Adobe's iFilter) and anti-virus. Still these PDfs don't replicate.
Lots of other files and filetypes are replicating just fine.
The makers of PDF995 haven't come up with any advice yet.
I'd be grateful for any ideas at all!
Regards
William K Rankine |
|
| Back to top |
|
 |
Richard Chinn [MSFT]
Guest
|
| Posted:
Tue Jul 19, 2005 8:52 am Post subject:
Re: PDF filetype not replicating |
|
|
There are a couple things that come to mind that may be causing the
problem.
1) Sharing violations. If the application you're using does not close
the file handle after it creates the PDF, then FRS will not replicate
it. This can be checked by exiting the application. It would also be
good to verify the actual process exits by using the Task Manager. If
the process exits, then this is most likely not a sharing violation.
2) The file is getting filtered. FRS has directory and file filters.
The following KBs have information about how filters are handled (note
in spite of the title, these do apply to Windows Server 2003).
http://support.microsoft.com/?kbid=296944
http://support.microsoft.com/?kbid=229928
One thing that is also filtered are files that have the
FILE_ATTRIBUTE_TEMPORARY bit set. It is not easy to see this bit
using the shell or the attrib.exe command. You can use a program like
filemon.exe from SysInternals to see what's going on when the
problematic application creates PDFs. After the application creates
the PDF, try doing the following.
type foo.pdf > nul
Look in the filemon output. If you see the file's attributes get
reported with a "T" then the temporary attribute is set and FRS won't
replicate it. It might look like the following lines.
9:24:54 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: TA
or
9:25:05 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: A
You can write a custom application to get around this and change the
attributes. Or you can copy the file to a new name and then copy it
back on top (renames and moves won't work). Unfortunately, there's no
easy way to discover these files and switch the temporary attribute to
off.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Tue, 12 Jul 2005 16:15:49 +0100, William K Rankine
<news@no-spam-infox.co.uk> wrote:
| Quote: | What can stop DFS / FRS replicating a particular type of file?
We use PDF995 to create PDFs of Word documents, CAD drawings and so
on. No PDF cerated by PDF995 will replicate. No error, it just sits
there.
If we use Adobe Acrobat to crate the PDF, it is replicated.
We've tried creating with PDF with PDF995 to a local hard disk then
copying it to the folder being replicated (in case it was an odd
locking issue). We've disabled content indexing (which was using
Adobe's iFilter) and anti-virus. Still these PDfs don't replicate.
Lots of other files and filetypes are replicating just fine.
The makers of PDF995 haven't come up with any advice yet.
I'd be grateful for any ideas at all!
Regards
William K Rankine |
|
|
| Back to top |
|
|
Richard Chinn [MSFT]
Guest
|
| Posted:
Wed Jul 20, 2005 8:52 am Post subject:
Re: PDF filetype not replicating |
|
|
I found an alternative to filemon for viewing the temporary attribute
bit. You can use fsutil.exe. It will output something like this:
Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x000900000000417b
Parent FileRef# : 0x000f000000003fe1
Usn : 0x0000000000000000
Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x2d6
File Attributes : 0x120
File Name Length : 0x10
File Name Offset : 0x3c
FileName : foo.txt
The key field is "File Attributes" that in the above example has
0x120. If you see a hex number with the 0x100 bit set (i.e. the
"100ths place" has an odd digit -- 1, 3, 5, 7, 9, B, D, F), then the
temporary attribute is set and FRS won't replicate it.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Mon, 18 Jul 2005 21:58:37 -0700, "Richard Chinn [MSFT]"
<rchinn@online.microsoft.com> wrote:
| Quote: | There are a couple things that come to mind that may be causing the
problem.
1) Sharing violations. If the application you're using does not close
the file handle after it creates the PDF, then FRS will not replicate
it. This can be checked by exiting the application. It would also be
good to verify the actual process exits by using the Task Manager. If
the process exits, then this is most likely not a sharing violation.
2) The file is getting filtered. FRS has directory and file filters.
The following KBs have information about how filters are handled (note
in spite of the title, these do apply to Windows Server 2003).
http://support.microsoft.com/?kbid=296944
http://support.microsoft.com/?kbid=229928
One thing that is also filtered are files that have the
FILE_ATTRIBUTE_TEMPORARY bit set. It is not easy to see this bit
using the shell or the attrib.exe command. You can use a program like
filemon.exe from SysInternals to see what's going on when the
problematic application creates PDFs. After the application creates
the PDF, try doing the following.
type foo.pdf > nul
Look in the filemon output. If you see the file's attributes get
reported with a "T" then the temporary attribute is set and FRS won't
replicate it. It might look like the following lines.
9:24:54 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: TA
or
9:25:05 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: A
You can write a custom application to get around this and change the
attributes. Or you can copy the file to a new name and then copy it
back on top (renames and moves won't work). Unfortunately, there's no
easy way to discover these files and switch the temporary attribute to
off.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Tue, 12 Jul 2005 16:15:49 +0100, William K Rankine
news@no-spam-infox.co.uk> wrote:
What can stop DFS / FRS replicating a particular type of file?
We use PDF995 to create PDFs of Word documents, CAD drawings and so
on. No PDF cerated by PDF995 will replicate. No error, it just sits
there.
If we use Adobe Acrobat to crate the PDF, it is replicated.
We've tried creating with PDF with PDF995 to a local hard disk then
copying it to the folder being replicated (in case it was an odd
locking issue). We've disabled content indexing (which was using
Adobe's iFilter) and anti-virus. Still these PDfs don't replicate.
Lots of other files and filetypes are replicating just fine.
The makers of PDF995 haven't come up with any advice yet.
I'd be grateful for any ideas at all!
Regards
William K Rankine |
|
|
| Back to top |
|
|
William K Rankine
Guest
|
| Posted:
Sat Jul 23, 2005 4:50 pm Post subject:
Re: PDF filetype not replicating |
|
|
The problem has been resolved. It's as if FRS won't replicate PDFs
compatible with old Acrobat (v4 or earlier, I think). We set an option
in our PDF-creating software to make our PDFs compatible with Acrobat
v6 and up instead, and they started replicating. I don't understand
why FRS should care about this - simplistically, isn't a file just a
chunk of data, as far as FRS is concerned? Well, obviously not.
William
On Tue, 19 Jul 2005 21:51:37 -0700, "Richard Chinn [MSFT]"
<rchinn@online.microsoft.com> wrote:
| Quote: | I found an alternative to filemon for viewing the temporary attribute
bit. You can use fsutil.exe. It will output something like this:
Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x000900000000417b
Parent FileRef# : 0x000f000000003fe1
Usn : 0x0000000000000000
Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x2d6
File Attributes : 0x120
File Name Length : 0x10
File Name Offset : 0x3c
FileName : foo.txt
The key field is "File Attributes" that in the above example has
0x120. If you see a hex number with the 0x100 bit set (i.e. the
"100ths place" has an odd digit -- 1, 3, 5, 7, 9, B, D, F), then the
temporary attribute is set and FRS won't replicate it.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Mon, 18 Jul 2005 21:58:37 -0700, "Richard Chinn [MSFT]"
rchinn@online.microsoft.com> wrote:
There are a couple things that come to mind that may be causing the
problem.
1) Sharing violations. If the application you're using does not close
the file handle after it creates the PDF, then FRS will not replicate
it. This can be checked by exiting the application. It would also be
good to verify the actual process exits by using the Task Manager. If
the process exits, then this is most likely not a sharing violation.
2) The file is getting filtered. FRS has directory and file filters.
The following KBs have information about how filters are handled (note
in spite of the title, these do apply to Windows Server 2003).
http://support.microsoft.com/?kbid=296944
http://support.microsoft.com/?kbid=229928
One thing that is also filtered are files that have the
FILE_ATTRIBUTE_TEMPORARY bit set. It is not easy to see this bit
using the shell or the attrib.exe command. You can use a program like
filemon.exe from SysInternals to see what's going on when the
problematic application creates PDFs. After the application creates
the PDF, try doing the following.
type foo.pdf > nul
Look in the filemon output. If you see the file's attributes get
reported with a "T" then the temporary attribute is set and FRS won't
replicate it. It might look like the following lines.
9:24:54 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: TA
or
9:25:05 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: A
You can write a custom application to get around this and change the
attributes. Or you can copy the file to a new name and then copy it
back on top (renames and moves won't work). Unfortunately, there's no
easy way to discover these files and switch the temporary attribute to
off.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Tue, 12 Jul 2005 16:15:49 +0100, William K Rankine
news@no-spam-infox.co.uk> wrote:
What can stop DFS / FRS replicating a particular type of file?
We use PDF995 to create PDFs of Word documents, CAD drawings and so
on. No PDF cerated by PDF995 will replicate. No error, it just sits
there.
If we use Adobe Acrobat to crate the PDF, it is replicated.
We've tried creating with PDF with PDF995 to a local hard disk then
copying it to the folder being replicated (in case it was an odd
locking issue). We've disabled content indexing (which was using
Adobe's iFilter) and anti-virus. Still these PDfs don't replicate.
Lots of other files and filetypes are replicating just fine.
The makers of PDF995 haven't come up with any advice yet.
I'd be grateful for any ideas at all!
Regards
William K Rankine |
|
|
| Back to top |
|
|
Paul Williams [MVP]
Guest
|
| Posted:
Sat Jul 23, 2005 4:50 pm Post subject:
Re: PDF filetype not replicating |
|
|
Perhaps the bit that Richard mentioned was set in earlier PDF files?
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net |
|
| Back to top |
|
|
Richard Chinn [MSFT]
Guest
|
| Posted:
Tue Jul 26, 2005 8:44 am Post subject:
Re: PDF filetype not replicating |
|
|
I'm glad you have a workaround for your replication issue, but FRS is
unaware of file contents and file types beyond the name-based file
filters that I mentioned. There is something else at play here.
You are right that the file is a simple chunk of data as far as FRS is
concerned.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Sat, 23 Jul 2005 14:05:56 +0100, William K Rankine
<news@no-spam-infox.co.uk> wrote:
| Quote: | The problem has been resolved. It's as if FRS won't replicate PDFs
compatible with old Acrobat (v4 or earlier, I think). We set an option
in our PDF-creating software to make our PDFs compatible with Acrobat
v6 and up instead, and they started replicating. I don't understand
why FRS should care about this - simplistically, isn't a file just a
chunk of data, as far as FRS is concerned? Well, obviously not.
William
On Tue, 19 Jul 2005 21:51:37 -0700, "Richard Chinn [MSFT]"
rchinn@online.microsoft.com> wrote:
I found an alternative to filemon for viewing the temporary attribute
bit. You can use fsutil.exe. It will output something like this:
Major Version : 0x2
Minor Version : 0x0
FileRef# : 0x000900000000417b
Parent FileRef# : 0x000f000000003fe1
Usn : 0x0000000000000000
Time Stamp : 0x0000000000000000 12:00:00 AM 1/1/1601
Reason : 0x0
Source Info : 0x0
Security Id : 0x2d6
File Attributes : 0x120
File Name Length : 0x10
File Name Offset : 0x3c
FileName : foo.txt
The key field is "File Attributes" that in the above example has
0x120. If you see a hex number with the 0x100 bit set (i.e. the
"100ths place" has an odd digit -- 1, 3, 5, 7, 9, B, D, F), then the
temporary attribute is set and FRS won't replicate it.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Mon, 18 Jul 2005 21:58:37 -0700, "Richard Chinn [MSFT]"
rchinn@online.microsoft.com> wrote:
There are a couple things that come to mind that may be causing the
problem.
1) Sharing violations. If the application you're using does not close
the file handle after it creates the PDF, then FRS will not replicate
it. This can be checked by exiting the application. It would also be
good to verify the actual process exits by using the Task Manager. If
the process exits, then this is most likely not a sharing violation.
2) The file is getting filtered. FRS has directory and file filters.
The following KBs have information about how filters are handled (note
in spite of the title, these do apply to Windows Server 2003).
http://support.microsoft.com/?kbid=296944
http://support.microsoft.com/?kbid=229928
One thing that is also filtered are files that have the
FILE_ATTRIBUTE_TEMPORARY bit set. It is not easy to see this bit
using the shell or the attrib.exe command. You can use a program like
filemon.exe from SysInternals to see what's going on when the
problematic application creates PDFs. After the application creates
the PDF, try doing the following.
type foo.pdf > nul
Look in the filemon output. If you see the file's attributes get
reported with a "T" then the temporary attribute is set and FRS won't
replicate it. It might look like the following lines.
9:24:54 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: TA
or
9:25:05 PM cmd.exe:3088 QUERY INFORMATION E:\xxx.txt
SUCCESS Attributes: A
You can write a custom application to get around this and change the
attributes. Or you can copy the file to a new name and then copy it
back on top (renames and moves won't work). Unfortunately, there's no
easy way to discover these files and switch the temporary attribute to
off.
--Richard
Please post FRS related questions to
microsoft.public.windows.server.dfs_frs and prefix the subject line
with "FRS:" to make it easier to spot. Note that FRS is used to
replicate SYSVOL on domain controllers and DFS root and link targets.
For additional FRS resources, please visit
http://www.microsoft.com/frs.
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Tue, 12 Jul 2005 16:15:49 +0100, William K Rankine
news@no-spam-infox.co.uk> wrote:
What can stop DFS / FRS replicating a particular type of file?
We use PDF995 to create PDFs of Word documents, CAD drawings and so
on. No PDF cerated by PDF995 will replicate. No error, it just sits
there.
If we use Adobe Acrobat to crate the PDF, it is replicated.
We've tried creating with PDF with PDF995 to a local hard disk then
copying it to the folder being replicated (in case it was an odd
locking issue). We've disabled content indexing (which was using
Adobe's iFilter) and anti-virus. Still these PDfs don't replicate.
Lots of other files and filetypes are replicating just fine.
The makers of PDF995 haven't come up with any advice yet.
I'd be grateful for any ideas at all!
Regards
William K Rankine |
|
|
| Back to top |
|
|
William K Rankine
Guest
|
| Posted:
Mon Aug 08, 2005 8:51 pm Post subject:
Re: PDF filetype not replicating |
|
|
On Sat, 23 Jul 2005 14:21:32 +0100, "Paul Williams [MVP]"
<ptw2001@hotmail.com> wrote:
| Quote: | Perhaps the bit that Richard mentioned was set in earlier PDF files?
|
Aha. Among the several things we tried was making the software send
its output to a temporary file first, instead of creating the PDF
directly on the server. I wonder if actually that fixed it?
Anyway, the important thing is it's sorted.
Thanks for everyone's interest and help. |
|
| Back to top |
|
|
Paul Williams [MVP]
Guest
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in