[fcastillo]

When I try to sync some of my playlist to a different drive, ext4 formatted, I always get an error that something couldn't get copied. The error is always for the playlist files.
When syncronizing I always make a playlist file at the destination, and this file is the one that never gets copied.
I can see the file in the destination folder, but it has really weird permissions: ---xr-Sr-T
Also the file is always empty (0 bytes)
I've tried synchronizing to a NTFS drive and didn't have any problem.
Any ideas what's going on and how to fix it?

[rsjtdrjgfuzkfg]

(04-26-2014, 04:15 AM)fcastillo Wrote: Any ideas what's going on and how to fix it?

From the file permissions, I'd guess that that file is not writeable without chmod'ing it. You wrote that you create the file, why? Or did you mean that Nightingale creates the file while syncing?
Any suspicious messages in the error console?

[fcastillo]

(04-28-2014, 07:27 AM)rsjtdrjgfuzkfg Wrote: From the file permissions, I'd guess that that file is not writeable without chmod'ing it. You wrote that you create the file, why? Or did you mean that Nightingale creates the file while syncing?
Any suspicious messages in the error console?

Yes, the file is not writeable unless a chmod it. Sorry if I wasn't too clear in the first post. Nightingale creates the playlist file at the destination. It's just that there's the option of not creating this file, then there's no problem but I need to have this file created by nightingale.
I checked the error console but didn't find anything there, I have no idea why nightingale would put those weird permission on the file.

[rsjtdrjgfuzkfg]

(04-28-2014, 11:24 PM)fcastillo Wrote: I checked the error console but didn't find anything there, I have no idea why nightingale would put those weird permission on the file.

Oh. Found it. My fault (sync.js:1079). I somehow typed the permission in hex (yeah, me being really stupid there)... and that setting only affects linux-permission-capable filesystems.

I fixed it in the foldersync repository, and I will backport the change to NG in some minutes, once the build verifies it did not do any harm there. Currently, the foldersync repository contains an experimental conversion feature that recived not enough feedback to be merged into NG (as it is potentially platform-dependent and hard to use), so I can't merge directly.

Update: fixed now, if you wish to get the fix without installing a new version of Nightingale, download and install the attached extension; it overrides the whole synchronization feature.

Update 2: If you don't have a forum account, you can download the file from the wiki as well: foldersync_3.0.4.3_dev-201404282205.xpi

[fcastillo]

(04-29-2014, 07:34 AM)rsjtdrjgfuzkfg Wrote:

(04-28-2014, 11:24 PM)fcastillo Wrote: I checked the error console but didn't find anything there, I have no idea why nightingale would put those weird permission on the file.

Oh. Found it. My fault (sync.js:1079). I somehow typed the permission in hex (yeah, me being really stupid there)... and that setting only affects linux-permission-capable filesystems.

I fixed it in the foldersync repository, and I will backport the change to NG in some minutes, once the build verifies it did not do any harm there. Currently, the foldersync repository contains an experimental conversion feature that recived not enough feedback to be merged into NG (as it is potentially platform-dependent and hard to use), so I can't merge directly.

Thanks for taking the time to fix it.
Will this change be also ported to the Ubuntu repositories for the stable version in launchpad?

[rsjtdrjgfuzkfg]

(04-29-2014, 07:42 AM)fcastillo Wrote: Will this change be also ported to the Ubuntu repositories for the stable version in launchpad?

Once we do a release, the fix will be pushed to stable repositories. But I don't think that is too soon, use the attached extension (last post) as a workaround.

[fcastillo]

(04-29-2014, 08:32 AM)rsjtdrjgfuzkfg Wrote: Once we do a release, the fix will be pushed to stable repositories. But I don't think that is too soon, use the attached extension (last post) as a workaround.

Thanks for the extension, it's working great. All playlist are being copied without a problem.
I should mention that there's another problem now, not as severe as the previous one. When synchronizing to a different ext4 partition/drive, to the root directory, and selecting the option to "delete all other files and folders from the target folder" I get an error since the extension tries to delete the lost+found folder in the root folder, which can't and shouldn't be deleted.
I think the extension should have an exception when deleting files and folders to avoid this specific folder.

[rsjtdrjgfuzkfg]

(04-30-2014, 04:07 AM)fcastillo Wrote: I think the extension should have an exception when deleting files and folders to avoid this specific folder.

I'm not a big fan of platform-specific rules like that. What if somebody on another filesystem wants a folder "Lost+Found" to be deleted? Imho the current behaviour is quite logical, while excluding a specifically-named folder is not (on other platforms / filesystems). Is there anything preventing you from using a subfolder instead?

In the future, I could think of an expert option in regards to that matter, though.

[freaktechnik]

Other OS (like windows") make the trash folder hidden, so such situations wouldn't occur. Also "lost+found" is case sensitive, as it's *nix.