<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Library Book Files save as 'Scratch' files. in Documentation</title>
    <link>https://community.graphisoft.com/t5/Documentation/Library-Book-Files-save-as-Scratch-files/m-p/110113#M17608</link>
    <description>&lt;DIV class="actalk-migrated-content"&gt;We are increasingly finding that, when we resave an LBK file, the original file remains intact and a new 'scratch file' is created. There is no warning issued - so we are only aware of the problem if we happen to notice that recent changes are not saved when next opening the LBK file.&lt;BR /&gt;&lt;BR /&gt;To avoid the problem, we are working on our desktops, and dragging the files back to the network at 'close of play' - but this is far from ideal.&lt;BR /&gt;&lt;BR /&gt;We are running on Macs under OS X, networked to a Windows server - and think that the problem may be to do with our server. But is the 'scratch' file created by the server, or by Plotmaker?&lt;/DIV&gt;</description>
    <pubDate>Mon, 10 Feb 2025 15:00:33 GMT</pubDate>
    <dc:creator>Anonymous</dc:creator>
    <dc:date>2025-02-10T15:00:33Z</dc:date>
    <item>
      <title>Library Book Files save as 'Scratch' files.</title>
      <link>https://community.graphisoft.com/t5/Documentation/Library-Book-Files-save-as-Scratch-files/m-p/110113#M17608</link>
      <description>&lt;DIV class="actalk-migrated-content"&gt;We are increasingly finding that, when we resave an LBK file, the original file remains intact and a new 'scratch file' is created. There is no warning issued - so we are only aware of the problem if we happen to notice that recent changes are not saved when next opening the LBK file.&lt;BR /&gt;&lt;BR /&gt;To avoid the problem, we are working on our desktops, and dragging the files back to the network at 'close of play' - but this is far from ideal.&lt;BR /&gt;&lt;BR /&gt;We are running on Macs under OS X, networked to a Windows server - and think that the problem may be to do with our server. But is the 'scratch' file created by the server, or by Plotmaker?&lt;/DIV&gt;</description>
      <pubDate>Mon, 10 Feb 2025 15:00:33 GMT</pubDate>
      <guid>https://community.graphisoft.com/t5/Documentation/Library-Book-Files-save-as-Scratch-files/m-p/110113#M17608</guid>
      <dc:creator>Anonymous</dc:creator>
      <dc:date>2025-02-10T15:00:33Z</dc:date>
    </item>
    <item>
      <title>Re: Library Book Files save as 'Scratch' files.</title>
      <link>https://community.graphisoft.com/t5/Documentation/Library-Book-Files-save-as-Scratch-files/m-p/110114#M17609</link>
      <description>&lt;BLOCKQUOTE&gt;Keith wrote:&lt;BR /&gt;But is the 'scratch' file created by the server, or by Plotmaker?&lt;/BLOCKQUOTE&gt;
the scratch file would be created by plotmaker because (more than likely) it is unable to delete the original. this would mean a permissions problem on your server . . . which you are actually making worse by having the file change ownership every time it's copied back to the server!  &lt;IMG src="https://community.graphisoft.com/legacyfs/online/emojis/icon_biggrin.gif" style="display : inline;" /&gt; &lt;BR /&gt;
&lt;BR /&gt;
i've never seen a windows server package, but i always had our mac server set to write the permissions of a file/folder based on the enclosing folder's permissions ('inherit from parent') rather than from the user that is saving the file . . .&lt;BR /&gt;
&lt;BR /&gt;
i'd start by looking for something similar on your windows server . . .&lt;BR /&gt;
&lt;BR /&gt;
HTH&lt;BR /&gt;
~/archiben</description>
      <pubDate>Thu, 23 Jun 2005 23:30:26 GMT</pubDate>
      <guid>https://community.graphisoft.com/t5/Documentation/Library-Book-Files-save-as-Scratch-files/m-p/110114#M17609</guid>
      <dc:creator>__archiben</dc:creator>
      <dc:date>2005-06-23T23:30:26Z</dc:date>
    </item>
  </channel>
</rss>

