Bug 14150 - Exporting from macOS Adobe Illustrator creates multiple copies
Summary: Exporting from macOS Adobe Illustrator creates multiple copies
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks: 14320
  Show dependency treegraph
 
Reported: 2019-10-03 13:16 UTC by Ralph Böhme
Modified: 2020-04-09 07:17 UTC (History)
2 users (show)

See Also:


Attachments
WIP patch for master (907 bytes, patch)
2019-10-03 13:16 UTC, Ralph Böhme
no flags Details
git-am fix for 4.12.next (35.76 KB, patch)
2020-03-30 20:28 UTC, Jeremy Allison
slow: review+
Details
git-am fix for 4.11 (6.88 KB, patch)
2020-03-30 20:46 UTC, Jeremy Allison
slow: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2019-10-03 13:16:23 UTC
Created attachment 15507 [details]
WIP patch for master

There's an ussue when exporting from Adobe Illustrator package directly to a Samba share.

When exporting a project that contains several copies of the same image, multiple number of files are created instead of having just one file.

Steps to reproduce:

  1.  Create an illustrator project with few copies of the same image, so the same image
      will be used many times in the same project.
  2.  Go to Files -> export
  3.  Go to the destination folder--> enter the Links folder --> the folder will contain
      multiple images (as the number of links).

Expected behavior:

The links folder should contain only one copy of file that being used in the project.

The same works correctly against a Windows server.

The problem seems to be, that the image file's modification date is not set to the correct value as requested by the client

There's a strange interaction between a write on a file handle followed by an explicit set of the filesize on the same file handle and a following explicit set of the write time on second handle that affects the observable write time of the file on the first handle when it's closed.

Windows servers returns the explicitly set write time, Samba returns the time when the handle that did the write IO is closed.

It seems setting the filesize on a handle immediately flushed any pending write time updates, so the write time is not updated when the handle is closed.
Comment 1 Ralph Böhme 2019-10-03 13:16:52 UTC
This needs careful review and testing against Windows.
Comment 2 Jeremy Allison 2019-10-03 19:14:38 UTC
Why make this optional ? If it makes us match what Windows does we should just enable it unreservedly (IMHO). Of course, more testing would help nail down the exact Windows behavior here.
Comment 3 Jeremy Allison 2020-03-30 20:28:43 UTC
Created attachment 15876 [details]
git-am fix for 4.12.next

Cherry-picked from master
Comment 4 Jeremy Allison 2020-03-30 20:46:17 UTC
Created attachment 15877 [details]
git-am fix for 4.11

Back-ported from the 4.12 fix. Note - the source4/torture/smb2/timestamps.c patches are not included as 4.11 doesn't have that test. Only the smbd changes are present in this patchset.
Comment 5 Ralph Böhme 2020-04-06 14:09:40 UTC
Reassigning to Karolin for inclusion in 4.11 and 4.12.
Comment 6 Karolin Seeger 2020-04-07 08:05:31 UTC
(In reply to Ralph Böhme from comment #5)
Pushed to autobuild-v4-{11,12}-test.
Comment 7 Karolin Seeger 2020-04-09 07:17:45 UTC
Pushed to both branches.
Closing out bug report.

Thanks!